Realtek 8111G Support
-
I also own a Shuttle DS47 that I wanted to use to replace my existing pfSense hardware in my home network. As others have found out, the NIC's on the device are Realtek 8111G, which aren't supported on FreeBSD 8.3, 8.4 or 9.2, so also not on pfSense 2.0x or 2.1.
As mentioned in an earlier post, there is source code to build a FreeBSD kernel module on the Realtek Website, which I used to do exactly that.
The module was build on a FreeBSD 8.3p11 installation (pfSense 2.1) and tested on FreeBSD 8.3 and with pfSense 2.1-RELEASE.
The attached module should be placed in /boot/kernel/ and the file /boot/loader.conf should be modified to include the line 'if_re_load="YES"' (in a pfSense full install; nano could be different, don't know)Because I had a bit of trouble getting an editor to work properly when booted into single user mode (WARNING: shell not fully functional?), I include a copy of the 'loader.conf' file so it can just be copied to it's location. Of course, this is a standard 'loader.conf' from a fresh 2.1-RELEASE install.
If more detail is needed, ask.
I did some very simple testing with the NIC's on FreeBSD 8.3 and they seem to work fine. Copying files on my network gets me around 70MB/s transfer speed, which seems reasonable for something like a DS47. (I get 100MB/s between Windows8 and FreeNAS9). I had it 'wget'ting a lot of files from the internet and it used my full bandwidth for hours, without problems.
On the other hand, I'm having a hard time getting pfSense 2.1-RELEASE to work with it. I'm using PPPOE over a VLAN on the WAN side to connect to my ISP. I'm doing that right now with a pfSense box (2.03), so it can work. I now get very erratic behaviour; while it sometimes connects for a very short time it usually does nothing. I haven't spent a lot of time debugging this, it could still be PICNIC… I had expected to just copy my config from the 2.03 box and be done with it, but things are never simple...
so my final verdict on the pfSense install is still to come...Two files attached in a gzipped tar: the kernel module (if_re.ko) & loader.conf. NOTE: Please remove the .txt extension.
Richard
-
Great work Richard
I will test it in the next days
g.
thomas -
Nice! :)
Can you give us a link to the source for that module? Is it 32 or 64bit?You should probably put the modules in /boot/modules and add the line to /boot/loader.conf.local but either will work. The file loader.conf.local gets copied across an update but the modules won't (in Nano at least) so you might want to keep a copy handy. Create loader.conf.local if it doesn't exist.
Steve
-
Nice! :)
Can you give us a link to the source for that module? Is it 32 or 64bit?Mhh, should have mentioned that… :-\ . I compiled the driver with FreeBSD 8.3-RELEASE-amd64 p11. The link to the source code is given in the first post of this thread, by the OP:
http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false
Description version update time size
FreeBSD 7.x and 8.0 1.83 2013/5/16 64kBrowsing through that source code, it looks like it is really old, no specific mention of the 8111G. The Realtek page header says it IS for the 8111G (among others). The included 'Readme.txt' only mentions the 8168G which seems to use the same driver as the 8111G. Maybe it's basically the same device, don't know.
When using a FreeBSD 8.3-RELEASEp11 (or 9.2-RC4) with the standard re(4) driver, the kernel complains about an unknown hardware revision for re0/re1 (0x4c000000). When I scan the Realtek source code for that, it looks like i'm getting a hit so I decided to just build the module, because it is really simple. Trial and error...
Regarding the 32/64bit issue i kinda hoped that the driver source code itself isn't specific for either one. It's compiling the module that makes the difference. The examples given by Realtek are about i386, i just substituted the pathnames with amd64. Experimenting a little is always fun :)
You should probably put the modules in /boot/modules and add the line to /boot/loader.conf.local but either will work. The file loader.conf.local gets copied across an update but the modules won't (in Nano at least) so you might want to keep a copy handy. Create loader.conf.local if it doesn't exist.
Okay, we'll do that.
The driver still seems to work fine with FreeBSD, I'll see if the weekend brings an opportunity to test it with pfSense again. If someone could point me to some good current info about setting up pfSense with PPPOE over a vlan on the WAN side, I'd be grateful. It seems easy enough, but even in 2.0x (where it works fine now) I found it difficult. Probably just me…
Richard
PS: is it just me or is the verification picture REALLY difficult to read? 2 posts and 10 tries just seems wrong.....
-
Update:
Because I could not get 2.1-RELEASE-amd64 to work with the DS47 with the newly compiled Realtek 8111G driver, I decided to build the driver again with the i386 version of FreeBSD. After installing pfSense 2.1-RELEASE-i386 and using the compiled kernel module, pfSense crashed with a kernel panic every time I plugged in the WAN connection. If I left the WAN connection unplugged, pfSense would boot up normally and let me go through all the configuration options without problems. Plug in the WAN cable: boom, kernel panic.. >:(
So I decided to try pfSense 2.03. This is what I'm using right now, on another box, and it works fine (and has for years, with previous versions, same hardware).
So installed FreeBSD 8.1 p13-amd64, build the module, installed pfSense 2.03, let it use the module: exactly the same behaviour as above. Kernel panic as soon as I plug in the WAN connection.
So, right now, nothing really works. I don't know exactly what is causing this. The driver seems to be working fine with FreeBSD plain, both 8.1 and 8.3. I copied hundred's of gigabytes over my network for hours without problems.
It could be that:
1 - the VLAN option is causing problems with the driver. I cannot test pfSense for real without it, that's how my ISP works.
2 - Something goes wrong when building the driver, although I would think it's really easy to do. But I'm no expert by any means.
3 - Using the module isn't enough, the standard re(4) driver that is compiled into the standard pfSense kernel should be removed.
4 - Something else… ::)I would really be interested if other people could test this and/or build their own kernel modules.
There is nothing more entertaining than spending your Sunday constantly breaking the family's internet connection. Mhhh...Richard.
PS: I'll attach the module build with FreeBSD 8.3-p11-i386 and 8.1-p13-amd64. Again, remove the .txt extension.
[FreeBSD Realtek Kernel module.tar.gz.txt](/public/imported_attachments/1/FreeBSD Realtek Kernel module.tar.gz.txt)
-
oh man you are my hero ;-)
I can't get an ip with my new fanless computer, this jetway got 2 Realtek RTL811EVL PCI-E Gigabit Ethernet LAN
You can check my thread here : http://forum.pfsense.org/index.php/topic,66464.msg363431.htmlI just tried your driver with 2.1 i386 and at first boot i got an ip for my WAN ;-)
Thanks a lot !
-
Glad it was at least useful to someone… :)
I'm still having problems with pfSense using the Realtek 8111G NIC's. Little more work to do, I guess.
I really wished Shuttle made these devices with Intel NIC's. They are so great for a pfSense home router. Wouldn't care if that increased the price somewhat.
Just curious: I assume you used the FreeBSD 8.3P11-i386 module from the last post? Because I forgot to mention the equivalent pfSense version; I guess that's easy enough to find though.
Just in case someone might want to know:
pfSense 2.1 is based on FreeBSD 8.3-RELEASE-p11
pfSense 2.03 is based on FreeBSD 8.1-RELEASE-p13Anyway, good luck with your router!
Richard
-
Just curious: I assume you used the FreeBSD 8.3P11-i386 module from the last post? Because I forgot to mention the equivalent pfSense version; I guess that's easy enough to find though.
Yes i knew that pfsense 2.1 is based on 8.3 and pfsense 2.0 based on 8.1.
And before i saw your message, i was testing some if_re.ko found on this forum.
My question : what will happen when a new version comes out ?
And can the developper of pfsense use the offcial 1.83 module of realtek ? -
pfSense is built on the FreeBSD code base. If Realtek, or whoever, submit their code or patches into FreeBSD it will get included in pfSense 2.2 which is expected to be based on FreeBSD 10.
It's hard to say quite what the source code on Realteks site is. It's clearly the same code as FreeBSD are using but comparing it with the FreeBSD re(4) source it looks old but it's been patched to support newer cards. :-\Steve
-
and if we have a new version of pfsense, still in 2.1 branch ?
-
Typically they would be for bug fixes or security fixes but drivers have been backported before to support newer hardware. If would require specific work to produce the patches though, it's unlikely updated freebsd drivers would be included automatically.
Steve
-
so if my router is stable with this driver i can safely put it in production ? i will just have to test the new pfsense 2.2 !
great news :)
-
Only you can make that decision. ;)
If you have thoroughly tested it and found it to be stable then it will probably be OK. Of course it will probably be subject to conditions in production that you haven't tested, that's just how it goes. BY running code that isn't part of the default pfSense install you don't get the benefit of thousands of other people testing it in production.Steve
-
i'm understantding but there is no warranty at all with pfsense except if you buy a specific hardware.
With i386 / amd64 installed on PC, there are a lot of components which can cause instability or errors so…I'll test it for a long time at my work, i'll see if it's stable or not :)
-
Thats a simple problem to avoid. Use hardware that is 2 - 3 years old and that is known to work well with pfsense with no special tweaking.
When people buy the latest and greatest, usually, they are cutting their own throat. PFsense is not windows 7.
When shopping for pfsense hardware, unless you love tinkering buy known-to-work hassle free hardware with recommended NICs.
-
i know that…
But i was looking for cheaper hardware for pfsense.
I have anothers pfsense router, certified, for 800 € !This one cost only 350€ and i have more functionnality (Wifi, 64 Gb SSD, Fanless, Atom).
Sometime it's good to test ;-)
-
I have Atom based systems out there and at home I use an old AMD X2. I prefer the AMD. It seems to do everything better, faster easier more stable. Seems the only place it doesn't work better than the Atom boxes is power consumption.
If you just need one, I'd say use a older, relatively low power desktop box you recycled.
If you need a bunch of them running, the the power becomes a factor. (for me anyway).
-
Great news:
FYI: Fixed in r257304-257306.
So for the next Version of PFSense I hope the Card will be also supported. At the moment I working with 4 DS47 with customized driver and everything will working perfectly - also with all my VLAN implementation.
g.
thomas -
Hello Thomas,
Very interesting!. What exactly are you working with on the DS47's? With FreeBSD or pfSense? Did you make kernel modules or are you using a FreeBSD version with these changes already applied? (10 or maybe even 11).
If I look through the source code, as far as I can tell, the 8011G is treated exactly like the F, which is already in FreeBSD 8.3. The only thing changed, seems to be that the hardware revision is added to 'if_rlreg.h' and a few lines in 'if_re.c' to get the 'G' treated exactly like the already implemented 'F'.
I tried that approach some time ago, when these changes started appearing on the internet. I took the the FreeBSD 8.3 source code for the Realtek NIC's and modified those files in exactly the same way as in the source code you mention in your post. Build kernel modules with it and used those.That didn't work at all… :-\ The NIC's were recognized during boot and when doing an 'ifconfig', if the NIC had a network connection, it was marked as 'UP'. After that nothing seem to happen. DHCP did not work and manually assigning an address to the NIC did seem to work, but no traffic would flow in or out of it. No error messages of any sort, it just did nothing.
I couldn't find out what was wrong with it and eventually gave up. Having a network card (or two) that refuse to move any network traffic seems rather pointless... :(I'm now using the DS47 with some Linux distro... works fine, but who wants to use Linux if FreeBSD/pfSense is a possibility? ;)
So I'm glad (and a little confused) that it seems to work fine with you. It wouldn't surprise me if I did something wrong, but applying these changes did not seem too difficult. Who knows?
I would appreciate it if you could give some details on how your setup works.
Richard
-
I have an ECS KBN-I/2100 motherboard which has an on-board Realtek nic, and I added a SYBA SY-PEX24028 dual-port Realtek gigabit card to have LAN, WAN, and Wi-Fi ports. But pfSense 2.1 would not work with these nics until I found your driver. Thank you very much! Its only been a couple of weeks in use on my own network, but they run smoothly with no issues so I'll be using them in a production machine being sold to a customer.
Until now I had a heck of a time making the nics work. I even tried installing the latest release of Freebsd to see if I could grab a working driver and install it into pfSense, but the newest Freebsd would not recognize the nics.
One solution was to install Ubuntu Server and run pfSense in a KVM virtual machine on the box. pfSense has no problems with the virtual nics available in KVM, however there was a performance penalty running on this 1 GHz dual-core processor.
What I like about these new, (relatively) fast AMD Kabini cpus is that they include AES-256 support, while the current low watt Intel Atoms and Celerons do not. (But there are new Atoms being released that do have AES)
Anyway, thanks again for the drivers!
