Samsung Captivate users who have reflashed their phones with Cognition, the GPS functionality tends to take a serious nosedive compared with the stock Rogers firmware. However, gdmuscle from the XDA Developers forum was able to figure out which files to pull from the original Rogers ROM that when used on the Cognition ROM seem to result in near perfect GPS performance.
Since my previous post about flashing my new Samsung Captivate from the stock Rogers ROM to the AT&T build of Android 2.2 I’ve flashed the device to a couple different versions of the Cognition ROMs. They’re certainly an improvement over the stock Rogers ROM, but Cognition is still based on the AT&T ROM, and I really do think that the Rogers ROM would actually be a better starting point because there is a lot less cruft. So, without further adieu here is my wishlist for a hybrid Rogers/Cognition ROM:
I think that swapping out the boot animations should be pretty simple, if I could figure out how to use make the bootsamsung.qmg files (which I believe are raw frame buffer files that are the animation) work from a bootanimation.zip file. A little more research and #2 could probably be solved. The other three require either more knowledge, or assistance from the guys who actually make Cognition.
I got the newly released Rogers Samsung Captivate, which is quite the upgrade from my rapidly aging iPhone 3G. My first impressions after just over 24 hours with the phone are good. However, the fact that it came running Android 2.1 (Eclair) rather than the newer 2.2 (Froyo) release bothered me. Though if you check the phone’s status, it says it’s running 2.1-update1, and it appears to include some of the features from 2.2. No Matter, what fun is a gadget you don’t risk turning into a brick within the first day of owning?
Here are the steps I took to reflash the device with a leaked version of the 2.2 ROM from AT&T, then root the device and remove all the AT&T bloatware and generally end up with a decent setup. As is typical of these sorts of posts it must be said that these steps worked for me, have not been tested on any other devices than my own, and may turn your phone into a brick, a nuclear killing machine, or less likely, a rabbit.
Or How I learned to stop worrying and love my dual WAN with routed subnet and policy based routing pf firewall
One of the reasons I continue to use FreeBSD for my gateway/router/firewall is the pf firewall. My routing needs are way more elaborate than anything a pre-cooked router package like DD-WRT or even pfSense can do, so I have to roll my own firewall. Currently I have two DSL connections, through two different companies. I have a dynamic IP connection from my employer, Primus Canda, and I have a static IP connection with a routed /30 subnet from TekSavvy.
My setup needs to satisfy the following requirements:
For the connection for the LAN, the traffic shaping needs to do the following:
For the connection with the routed subnet, the requirements are a little different:
This is all possible with pf, and I find the pf.conf format to be far more readable and thus less prone to errors than an iptables config file. To accomplish this I use packet tagging to label packets, and then use policy based routing to direct and control the traffic.
I’ve been running Multilink PPP with FreeBSD for several years now. Multilink PPP (sometimes called MLPPP) is a subset of the PPP protocol that allows you to bond multiple PPP tunnels and treat them as one much larger tunnel. Several DSL providers (particularly TekSavvy in Canada) support Multilink PPP on their DSL networks, allowing users to bond multiple DSL lines into one large pipe.
The technical details of Multilink PPP are pretty simple, though it can be configured in either a packet splitting or round robin fashion. When configured for packet splitting, a router that is about to transmit a packet down an MLPPP link will first split the packet in half, then add a 6KB MLPPP header (really just a sequence number) to each half of the packet, and send the half-packets down each link. On the other end of the MLPPP link, the receiving router will take the two halves (identified by the matching MLPPP headers) and reconstitute the original packet. In round robin mode the MLPPP header is added to the whole packet (meaning the MTU of the link is 6KB smaller or else packet fragmentation will occur) and sent out the links in a round robin fashion.
In FreeBSD it’s easy to setup just about any Multilink PPP configuration you want. I’ve run it with three DSL lines (total usable throughput: 15 megabits). Presently I’m running over one DSL line but with two PPPoE tunnels first multiplexed at the DSL frame level and then bonded at the PPP level. The purpose of this is to circumvent Bell Canada’s throttling, which they apply to both their own residential customers and to their third-party wholesale partners, like TekSavvy.