Putting Freebsd on little Wi-Fi router devices
adrianchadd.blogspot.com
adrianchadd.blogspot.com
The problem is, FreeBSD cannot properly run sshuttle - it can do it for regular traffic, and it works well, but it cannot do DNS lookups for the entire network over the tunnel. This shortcoming is documented by the sshuttle README @ github.[1]
I am very interested in having this fixed / worked around and am willing to PAY SOMEONE TO FIX IT. If anyone out there is interested in (finally) getting sshuttle working on FreeBSD, please email info@rsync.net and we can discuss.
In any case, since 2011 sshuttle has supported DNS interception via a divert socket, so although it might not work today I suspect it should be somewhat straightforward to fix. I haven't looked into this yet as my only use case for sshuttle involves running it on the end host itself (typically my laptop).
However the new project has the same issues with DNS over VPN on FreeBSD. I have personally corresponded with the current maintainer, etc., and since they build and test only on Linux, it's not something that ever got fixed.
If you read the original HOWTO/README from the original project, it details the issues and I can confirm that no amount of settings changes or workarounds will allow you to get DNS over the tunnel on FreeBSD.
The threads I have managed to find largely amount to "it doesn't work." Are you aware of anywhere the specific details of the issue are posted (debug logs from sshuttle, packet captures, etc.)?
You'll need a small contraption to be able to reset the device remotely. If you have a friend who knows a thing or two about hardware, he can come up with one in a few hours (it just needs to momentarily interrupt the connected device's power supply).
Thanks for working on this. My friend has been looking at doing some consulting and wanted to be able to distribute low cost FreeBSD-based routers. Now the framework is here...
Not sure I get this criticism.
To my understanding, downvoting is a judgement of a specific comment. It is neither about the person who wrote it, nor about whatever else that person wrote.
In particular, I don't see how these donvotes diminished the author's work on that article in any way. The 50 upvotes (currently) on that article tell an entirely different story.
Nothing.
It was downvoted because it looked like a stranger telling someone what to do.
more directly: how'd you do what you did? :)
If it's the same SoC in a different box, then it isn't too hard:
* Attach serial console, boot to uboot. If you're using a d-link then you likely can't without some hardware hacking (and even then they sometimes disable serial RX in u-boot. Grr.) If you're using tp-link then you mash 'tpl' at the console whilst uboot is counting down from 1 second -> 0 seconds to drop into the prompt. * Chances are an existing kernel will boot - you can test using tftpboot and go. So, build an existing image, grab kernel.BLAH from ../tftpboot/, put it somewhere tftp'able, and:
uboot> setenv ipaddr ip-for-AP uboot> setenv serverip ip-of-server uboot> tftpboot 0x80050000 kernel.BLAH uboot> go 0x80050100
Some uboots don't have 'go', only 'bootm'. In that case you can grab the kernel.BLAH.lzma.uboot file - it's a compressed u-boot application. You have to ensure you load it /above/ where FreeBSD boots from, as uboot will decompress it for you into the right spot (here it's loaded into 0x80050000.) I typically put it 16MB above (and thus assume you have at least 32MB RAM):
uboot> tftpboot 0x81050000 kernel.BLAH.lzma.uboot uboot> bootm 0x81050000
It should decompress the kernel and start running. If it's the same SoC, then it should boot.
There are a few things you'll need for the board, which typically you lift from the openwrt board config files :) :
* The ethernet setup (what mode each port is in, PLL setups, etc) * the ethernet switch setup (which switch, internal/external, whether ports are hooked up pass-through or to the switch itself, the port config, LED config, etc.) * The atheros onboard wifi and where in flash the calibration data is. * The MAC addresses - where in flash are they. * if there's PCI/PCIe devices, where that is and where in flash the calibration data is * What the GPIO setup looks like. * If there's any custom required GPIO hacks - like say, "wifi RX LNA on gpio X", "enable the serial UART GPIOs explicitly", etc.
That part will take a little more to describe. Maybe I should also write a blog post/wiki article about it. But if you get it to the point of tftpboot'ing on a new piece of hardware then I'll absolutely help you with the rest on IRC and we can write it up.
If it's a different SoC - that's a different article. I have support up to the QCA955x - I think I have two or three more newer SoCs and ethernet switches to write support for, and some more wifi support to port from their reference driver. If you really want to do /this/ part then I'll write that up separately. :)
I thought that most of the BSD world had transitioned to PF at this point. I checked FreeBSD handbook and indeed all three firewalls are supported: IPF, IPFW, PF. Are the older ones still really relevant?
1: https://svnweb.freebsd.org/base/head/etc/rc.firewall?view=ma...
ipfw is small, lightweight and fine for what I'm experimenting with.
If people want to include pf and send me a pull request with that as an option then by all means, please do!
It could be fun to take something like the BSD kernel and an alternative BSD licenced userland to make a much smaller footprint device, but I don't have the energy to /also/ do that.
If someone would like to do that then please do step up and do it! I wouldn't even mind if the FreeBSD wifi stack and Atheros MIPS support was ported back to NetBSD and NetBSD was used for this purpose.
Anyway, it was a good read, thanks.
I'll have to get on freebsd-mips and start getting annoying with my simpleton questions :)
otherwise it's just another beefy MIPS machine.