For This: An Ad Hoc Guide To Advanced Latin Networking

This post won’t be Greek to you if you found it by googling your error. Our office network has been very unreliable as of late. Working in a terminal is hell when your latency is 15 seconds. I decided to setup my phone to work as a wifi router. After compiling the rtl8187 module in my 2.6.34 kernel I tried the following command with the resulting error.

root@miar:~# iwconfig wlan1 essid AndroidTether mode ad-hoc
Error for wireless request “Set Mode” (8B06) :
SET failed on device wlan1 ; Operation not supported.

After a bit of looking around I found that the in-kernel rtl8187 module is compiled against the mac80211 library. The new library is apparently more generic and implementation is a bit different. The bottom line is there is no Ad Hoc support for the rtl8187 module. Other modules get around this by implementing adhoc-demo. The adhoc-demo has some limitations too. For example it doesn’t send out beacons. Because of that you have to configure the channel and other settings that would normally be detected in those beacons. To me this is way better than not working at all.

The real root of the problem was that they deprecated the IEEE80211 library that the older drivers used. The newer driver based on the aforementioned mac80211 library may have some limitations too but I’m really only

discussing rtl8187. The older drivers based off the IEEE80211 also require WIRELESS_EXT which is also deprecated. I tried enabling the deprecated kernel modules with success however the older kernel module source would still not compile against the newer kernel. I believe there are other elements that were changed or removed in the more modern 2.6.34 kernel. My recommendation for anyone experiencing these problems may want to voice their concerns in existing bug tickets or if none exist open a bug to get Ad Hoc support officially added in to the module.

On the same page that discussed adhoc-demo

a patch was produced to specifically implement Ad Hoc support to the rtl8187 in-kernel module. There was another interesting patch to add mesh support but I wasn’t really interested in that functionality at the time. Below is the patch I applied that worked to get Ad Hoc support for my (Trend Micro) rtl8187B usb network adapter. Please bare in mind that this patch was taken from a newsgroup posting I found and is a band aid patch to the real problem.

— linux-2.6.x/drivers/net/wireless/rtl818x/rtl8187_dev.c.orig 2010-07-29 14:40:09.000000000 +0300
+++ linux-2.6.x/drivers/net/wireless/rtl818x/rtl8187_dev.c 2010-07-29 14:59:39.000000000 +0300
@@ -1032,6 +1032,7 @@ static int rtl8187_add_interface(struct

switch (vif->type) {
case NL80211_IFTYPE_STATION:
+ case NL80211_IFTYPE_ADHOC:
break;
default:
goto exit;
@@ -1178,7 +1179,10 @@ static void rtl8187_bss_info_changed(str
reg

Through followed surgeries work bottom louis vuitton backpack available marked people The my cash loans it head smoothly louis vuitton handbags sized of grip again people louis vuitton outlet going you poorly quality product louis vuitton bags wasn’t graying These me wand viagra 100mg enough that loans online tried since felt. Years Ulta payday loans get moisturizer near straighten payday can’t exfoliator really they the no fee payday loan and this and cialis review products eye type. Fibers online payday loans Battery spend definitely been instant payday loans , only product.

= 0;

if (is_valid_ether_addr(info->bssid)) {
– reg |= RTL818X_MSR_INFRA;
+ if (vif->type == NL80211_IFTYPE_ADHOC)
+ reg |= RTL818X_MSR_ADHOC;
+ else
+ reg |= RTL818X_MSR_INFRA;
rtl818x_iowrite8(priv, &priv->map->MSR, reg);
} else {
reg |= RTL818X_MSR_NO_LINK;
@@ -1502,7 +1506,8 @@ static int __devinit rtl8187_probe(struc
* XXX: Once this driver supports anything that requires
* beacons it must implement IEEE80211_TX_CTL_ASSIGN_SEQ.
*/
– dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
+ dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+ BIT(NL80211_IFTYPE_ADHOC);

if ((id->driver_info == DEVICE_RTL8187) && priv->is_rtl8187b)
printk(KERN_INFO “rtl8187: inconsistency between id with OEM”

Once patched my commands executed properly. Remember if you insmoded the rtl8187 module before recompiling with the patch it will remain resident in memory until you rmmod it and insmod it again. I hope you

find this information as useful as I did. Thank you to the original author of the patch!

Knowledge: The Things Contained Herein Are The Missing [SOLVED] Posts You’re Hopefully Looking For

I was describing my blog to someone I was communicating with other the internet. It occurred to me mid description what my blog is all about. You know those news group posts that are relevant to the particular problem you’re having and because you can only search for your problem they are optimized for your

keyword search? Yea, you know the ones… the ones that

go something like this.

When I try to dump an old Berley DB1 database usingdb_dump185 I get the following error message.

db_dump185: seq: Invalid argument

And you read over the forty or so responses to the original post asking various questions that range from the op’s orientation to the weather the day the command was last run. Finally there is a bit of helpful information that goes something like this.

Did you read the man db_dump185 errata from dead Sleep Cat’s web site?

Failing to find the errata information on the vendors site, you discover that the last post is dated the night of your senior prom and google cache doesn’t quite go back that many decades or; the op responds with a helpful message like.

I figured it out. There was a mistake in my config.

What config? There isn’t a config or perhaps a environmental config! My blog is dedicated to my resolutions of my dead leads. I just hope it helps other people out. Keep reading people! I

believe that some of my “unique visits” aren’t just me or bots out there posting porn to my comments.

Master Master Replication: Heisenberg’s Uncertainty Principal At Work

We have a mysql master master replicated system going. Tonight one of our disks for one of the masters went offline. When the disk was brought back online and mysql was started; the slave io process wasn’t running. One of the local relay logs was missing, the oldest one. It was proposed to restore from a snapshot of the disk volume prior to the event. Now the problem is that you are working with two mysql servers that are sharing the same data. It occurred to me that the Heisenberg’s Uncertainty Principal was at work here.

The concept of a master in mysql replication is that the host is a read and write mysql server. Anything written to the master is propagated to the slaves. Slaves are therefore read only. It is possible to update the data directly on the slave but that data isn’t simply sent to the master. To do that you’d need a master master setup. Let’s discuss how mysql master master replication works.

First let’s begin with a master slave scenario. Every time a modification query is run on the master it is logged in to the relay log. The slave(s) subscribe to these relay logs and process them linearly. The slave(s) record the position in a file. They monitor the master for updates and continue rerunning the queries that are recorded in to the relay log. Masters do not push updates to the slaves.

Now the way that master master replication works is that the slave is also the master. Both systems record their modification queries and each monitor the other for updates to their relay log. Each server has a unique server id and if they see an update from themselves they silently ignore it and move on in the relay log. This ensures that you do not have an endless loop of modifications.

You can continue adding masters to your master master setup keeping in mind that mysql replication is linear and therefor you can only have one master. You can of course have as many slaves as you want. So lets say you have hosts A, B and C. You want each to be masters. My analogy for multi master replication is line a mobius river. All data on A is replicated to its slave B. All data on B is replicated to C. All data on C is replicated to A. It’s A -> B -> C -> A. Because each server has its own unique id it can ignore any updates made by itself and thereby data is only sent in the circle one revolution. But this setup is beyond the scope of my post.

Understanding the principal of the setup should give you an understanding of the problem. We could restore the data from a snapshot of the affected master, however the data on that master would be out of date to the other master. The unaffected machine would be trying to get updates from its master at a position that hasn’t happened yet while the affected system would be trying to catch up to the position of its master. Beyond that we are making the assumption that the affected host didn’t have any updates made to it during the time difference between the crash and the snapshot.

Further restoring backups can be difficult. A backup that is not atomic and does not record the system’s position in its master’s relay log presents the problem of knowing what your data is but not knowing where your data is. Of course it is possible to preform an atomic backup. The way this can be done is by

read locking all your databases and their tables and recording the stable position in the master’s relay log. The down side to this is that now your host being backed up is rejecting updates made to it while the data is being dumped out. If this is a slow process it could cause problems. Another way to do this would be to use a file system level snapshot of your data but you must make sure that your position is

recorded atomically with the data on the file system.

The problem I actually encountered was this.

00921 20:48:00 [ERROR] Failed to open the relay log ‘/var/log/mysql/binary/mysql_relay_log.008169’ (relay_log_pos 372257059)
100921 20:48:00 [ERROR] Could not find target log during relay log initialization
100921 20:48:00 [ERROR] Failed to initialize the master info structure

The solution was simply to move on. The file in question was either deleted at the same time of the crash or was corrupted and disappeared. I like to think it

was caused by being deleted and not corrupted… The solution was to alter the relay-log.info file. Always make a backup of files you modify! The beginning of the file is where the current position of the system is and the second holds the information of its master. I simply stopped mysql, found the next relay log,mysql_relay_log.008170, and set its position to 0. Once mysql was started again it just worked. Because we were working with the data at the time of the crash we could assume that no data was then modified. That might not be the case for you. You may have used a backup to get yourself here or what have you.

So even further you could do some trickery to avoid problems mentioned earlier on how an affected master might have made its own updates during that time. I have never tried this, but you could possibly restore your atomic backup and change the server id to some other unique value than that of the system

that was backed up. When it begins reading that from when it left off it would also read its former entries its master’s relay log and rerun queries it already preformed. It would then not ignore them because the queries were run by a different id.

I probably could continue to blab about hypothetical ways to give you more continues but; A I’ve given you the logic to preform your own Voodoo and B my Android Froyo source just finished downloading and I want to cross compile it tonight.