PFSense 2.2.4 (based on FreeBSD 10.1) recognizing a cable NIC as a wireless NIC (ndisgen driver)

P

pedrofln

We have fifteen ENL-832-TX-RENT (RTL8139D chipset) NIC's available and a need to use PFsense in some sites. There is a difficulty finding NIC's to buy in the market, so throwing those out is not a solution. The problem is that PFsense is not recognizing this NIC, although in it's compatibility list there is a ENL-832-TX listed.

What I have done so far:

I downloaded version 10.1 of FreeBSD and installed it in a virtual machine to start to play with this driver thing.

After installing it with the source code (necessary for the ndisgen to work correctly), I copied the .inf and .sys files to the root home directory and called the ndisgen utility. It generated a driver with .ko extension correctly.

I copied this file to the PFsense 2.2.4 /boot/modules directory. I have added a line in /boot/defaults/loader.conf with the "YES", and made the same for the ndis_load="YES" and if_ndis_load="YES" option for those modules to load at boot. The modules loaded okay, the NIC shows as active, shows the MAC address, etc. Everything seems to be fine, but the NIC was recognized in PFsense erroneously as a WLAN NIC, so when I go to assign interfaces the scripts ends with a ndis0: wlan_clone_create: reject, not a 802.11 device, and the NIC simply doesn't work (although it works like a charm in FreeBSD 10.1).

So...I am not a Linux expert and I think I'm starting to feel my limitations in this matter. So... Is there any config file I can change something for this NIC be recognized as a normal Ethernet card, and not as a Wireless NIC?

People will say: this is not the right place for PFsense questions, go to their forum. I have gone, but those guys there know absolutely nothing. The real PROs are HERE in this forum, so I decided to ask the issue here.

Anyway, the thread is open in PFSense forum. https://forum.pfsense.org/index.php?topic=98943.0
 
Please do not change entries if /boot/defaults/loader.conf. Those are defaults. If they need to be overridden, do that in /etc/rc.conf.

Using NDIS allows some wireless cards to work, but that's all it is really meant to do. The better fix would be to find the re(4) code in PFsense and merge in the updates from FreeBSD. Or see if https://opnsense.org/ has already done it, or is willing to do it.

It might be possible to build the kernel module on FreeBSD of the same version as whatever PFsense is using, and copy it over. But the PFsense kernel probably has that module built in, so it would have to be modified.
 
OPNsense 15.7 is based on FreeBSD 10.1, so it might do what you need already. It should be similar if not exactly identical to PFsense.
 
wblock@, thanks for the OPNsense tip! I didn't know about the product and it will be the way out for this situation. Although it did not recognize the NIC and I still had to use the ndisgen(8) utility to make it, I could use OPNsense to make the trick better than with pfSense.

I could make the NIC work both with pfSense and OPNsense, but pfSense always messes with the workaround and OPNsense is more open in the sense allowing the created bridge to be used as an interface and persist. I can't show here and say it's 100% because I left the office yesterday with the NIC pinging hosts and vice-versa.

After putting up the ndisgen(8) generated driver to load (the first part of the solution), I made a manual bridge associated with it. Then, edited manually the config.xml to point the LAN driver to bridge0. Then I went to assign interfaces and it worked like a charm in OPNsense (in this moment pfSense messes with the bridge).

Since it's an Independence Day's preceding weekend (Independence Day in Brazil is next Monday) I won't go to the office to make the rest of the tests (run the initial wizard and be sure it's a 100% ok solution).

This solution will make something very interesting: If 100% operational (I'll confirm that on Tuesday), it will allow ANY NIC to work with OPNsense, and, who knows pfSense developers make a more intelligent script in the time to create a wlan(4) interface or a normal bridge (that I had to create manually). It is not because a driver is an NDIS module that it will necessarily be a WLAN NIC.

That's it. It's inexpensive hardware, but that's what I had for next week. I work for Brazilian government, and buying stuff may take weeks or months and I did not had this time - and I am not a philanthropist to give my own money for the government office. I only had those cheap NIC's to make 10 pfSenses to act as VPN gateways. It will work with OPNsense and I could make it with what I had.

As I told, if this workaround proves good next week I'll make an article explaining how to use the trick step by step, so the community may benefit from it.
 
You must log in or register to reply here.
Back
Top