Linux kernel, wifi hack, security & Golang

在用vim的时候要经常搜索，但是有的时候会忘记＊和 # 这两个快捷键，所以记录如下

在通常模式下:

/ 向下查找

? 向上查找

* 向下查找当前光标下的单词

# 向上查找当前光标下的单词.

f{char} 跳到当前行,当前位置右边的{char}的位置. 如

using namespace std;

用f; 将会跳到;所在的位置.

F{char} 类似f{char},不过,是左边.

t{char} 类似f{char},不过,把光标放在{char}的前一个位置.

T{char} 类似t{char},不过,是左边.

; 重复t T f T 指令

, 朝相反方向重复t T f T 指令

–
Bian Jiang
Blog:  http://www.wifihack.net/

进来在作IGMP协议栈的解析，简单记录如下:

IGMPV3 Types

   There are two IGMP message types of concern to the IGMPv3 protocol
   described in this document:

      Type Number (hex)   Message Name
      -----------------   ------------

            0x11          Membership Query

            0x22          Version 3 Membership Report

   An implementation of IGMPv3 MUST also support the following three
   message types, for interoperation with previous versions of IGMP (see
   section 7):

           0x12          Version 1 Membership Report    [RFC-1112]

           0x16          Version 2 Membership Report    [RFC-2236]

IGMP V1 Query:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Type  |    Unused     |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IGMP V2 Query:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     | Max Resp Time |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IGMP V3 Membership Query Message: :

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x11  | Max Resp Code |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                              .                              -+
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Version 3 Membership Report Message

   Version 3 Membership Reports are sent by IP systems to report (to
   neighboring routers) the current multicast reception state, or
   changes in the multicast reception state, of their interfaces.
   Reports have the following format:

RFC 3376                         IGMPv3                     October 2002

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x22  |    Reserved   |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |  Number of Group Records (M)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [1]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [2]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               .                               |
      .                               .                               .
      |                               .                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [M]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each Group Record has the following internal format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Multicast Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                                                             -+
      .                               .                               .
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                         Auxiliary Data                        .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example:
Version 3 Membership Report Message
 22 00 ea 03     | Type: 22, Checksum: ea 03
 00 00 00 01     | Number of group recode 01
 04 00 00 00     | Recode type: 04, Number of Sources: 00 00
 ef ff ff fa      | Multicast Addr: 239.255.255.250

 Group Record Types

   There are a number of different types of Group Records that may be
   included in a Report message:

   o A "Current-State Record" is sent by a system in response to a Query
     received on an interface.  It reports the current reception state
     of that interface, with respect to a single multicast address.  The
     Record Type of a Current-State Record may be one of the following
     two values:

        Value  Name and Meaning
        -----  ----------------

          1    MODE_IS_INCLUDE - indicates that the interface has a
               filter mode of INCLUDE for the specified multicast
               address.  The Source Address [i] fields in this Group
               Record contain the interface's source list for the
               specified multicast address, if it is non-empty.

          2    MODE_IS_EXCLUDE - indicates that the interface has a
               filter mode of EXCLUDE for the specified multicast
               address.  The Source Address [i] fields in this Group
               Record contain the interface's source list for the
               specified multicast address, if it is non-empty.

   o A "Filter-Mode-Change Record" is sent by a system whenever a local
     invocation of IPMulticastListen causes a change of the filter mode
     (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to
     INCLUDE), of the interface-level state entry for a particular
     multicast address.  The Record is included in a Report sent from
     the interface on which the change occurred.  The Record Type of a
     Filter-Mode-Change Record may be one of the following two values:

          3    CHANGE_TO_INCLUDE_MODE - indicates that the interface
               has changed to INCLUDE filter mode for the specified
               multicast address.  The Source Address [i] fields
               in this Group Record contain the interface's new
               source list for the specified multicast address,
               if it is non-empty.

          4    CHANGE_TO_EXCLUDE_MODE - indicates that the interface
               has changed to EXCLUDE filter mode for the specified
               multicast address.  The Source Address [i] fields
               in this Group Record contain the interface's new
               source list for the specified multicast address,
               if it is non-empty.

   o A "Source-List-Change Record" is sent by a system whenever a local
     invocation of IPMulticastListen causes a change of source list that
     is *not* coincident with a change of filter mode, of the
     interface-level state entry for a particular multicast address.
     The Record is included in a Report sent from the interface on which
     the change occurred.  The Record Type of a Source-List-Change
     Record may be one of the following two values:

          5    ALLOW_NEW_SOURCES - indicates that the Source Address
               [i] fields in this Group Record contain a list of the
               additional sources that the system wishes to
               hear from, for packets sent to the specified
               multicast address.  If the change was to an INCLUDE
               source list, these are the addresses that were added
               to the list; if the change was to an EXCLUDE source
               list, these are the addresses that were deleted from
               the list.

          6    BLOCK_OLD_SOURCES - indicates that the Source Address
               [i] fields in this Group Record contain a list of the
               sources that the system no longer wishes to
               hear from, for packets sent to the specified
               multicast address.  If the change was to an INCLUDE
               source list, these are the addresses that were
               deleted from  the list; if the change was to an
               EXCLUDE source list, these are the addresses that
               were added to the list.

   If a change of source list results in both allowing new sources and
   blocking old sources, then two Group Records are sent for the same
   multicast address, one of type ALLOW_NEW_SOURCES and one of type
   BLOCK_OLD_SOURCES.

IGMP Query



IGMP Report



图来自  Linux Networking Architecture 17.3.4 Implementing IGMP

参考:
1. IGMPV1 rfc1112
2. IGMPV2 rfc2236
3. IGMPV3 rfc3376
4. Linux下IGMP以及多播路由分析
5. Design and Implementation of IGMPv3 for Linux (2000)  
6. Linux Kernel 2.6.26
7. 在线查看Kernel: http://lxr.linux.no/linux+v2.6.26/
8.  RFC3376 因特网组管理协议 第3版(译)
9.  Linux Networking Architecture (Chapter 17. IP Multicast for Group Communication)
10. Mapping IP Multicast to MAC-Layer Multicast 

之前使用Graphviz生成了一张mongoose的函数调用图，这里将讲是怎么生成的。

通过Graphvis生成mongoose的函数调用关系
基本的理论可以参考这里(http://www.ibm.com/developerworks/cn/linux/l-graphvis/), 思路如下:
1. 通过GCC的 -finstrument-functions 和 -g 选项，获得函数调用关系的地址.
2. 使用 Addr2line 将函数地址解析为函数名.
3. 精简函数跟踪数据(可以参考pvtrace, http://download.boulder.ibm.com/ibmdl/pub/software/dw/library/l-graphvis/pvtrace.zip)
4. 使用Graphvis生成图片.

具体的步骤:
1. 在我们编译mongoose的时候，加上 instrument.c 文件。
instrument.c 文件的作用是在我们执行文件的时候，会自动记录函数入口和出口的函数地址，并保存在当前目录下面的trace.txt文件里面。 注意: 在用gcc编译的时候一定要加 -finstrument-functions 和 -g 参数。

在mongoose的Makefile文件中增加instrument.c文件。
原文：

$(CC) $(LINFLAGS) mongoose.c main.c -s -o $(PROG)

改为:

$(CC) $(LINFLAGS) instrument.c mongoose.c  main.c -finstrument-functions -g -s -o $(PROG)

2. 编译mongoose.
make linux

3. 运行编译好的mongoose程序，并在当前目录生成一个trace.txt 文件。

3. 下载 pvtrace.zip 并编译。
回生成一个pvtrace程序，这个程序主要是从trace.txt和mongoose中提取函数地址对应的函数名，并生成graphivz的语法树。

4. 使用你编译好的文件pvtrace, 运行mongoose, 来获得graph.dot文件。

5. 使用Graph程序，生成图片, 前提是你必须安装graphivz
Debian/Ubuntu

sudo apt-get install graphviz.

安装完后运行:

dot -Tjpg graph.dot -o graph.jpg

6. Over.
效果图参考: http://wifihack.net/blog/2009/04/mongoose-start-function-call-use-graph/

instrument.c:

/********************************************************************
* File: instrument.c
*
* Instrumentation source — link this with your application, and
*  then execute to build trace data file (trace.txt).
*
* Author: M. Tim Jones <mtj@mtjones.com>
*
*/

#include <stdio.h>
#include <stdlib.h>

/* Function prototypes with attributes */
void main_constructor( void )
__attribute__ ((no_instrument_function, constructor));

void main_destructor( void )
__attribute__ ((no_instrument_function, destructor));

void __cyg_profile_func_enter( void *, void * )
__attribute__ ((no_instrument_function));

void __cyg_profile_func_exit( void *, void * )
__attribute__ ((no_instrument_function));

static FILE *fp;

void main_constructor( void )
{
fp = fopen( “trace.txt”, “w” );
if (fp == NULL) exit(-1);
}

void main_deconstructor( void )
{
fclose( fp );
}

void __cyg_profile_func_enter( void *this, void *callsite )
{
fprintf(fp, “E%p\n”, (int *)this);
}

void __cyg_profile_func_exit( void *this, void *callsite )
{
fprintf(fp, “X%p\n”, (int *)this);
}

Ref:
1. 用 Graphviz 可视化函数调用 http://www.ibm.com/developerworks/cn/linux/l-graphvis/

–EOF–

mongoose start function call use graph

I constructed a mongoose start function call use graphviz.

Links:

1.   Visualize function calls with Graphviz http://www.ibm.com/developerworks/library/l-graphvis/

这几天在解析ARP，ICMP 的时候, 要对数据进行移位，由于之前对unsigned 和 singned没有很好的认识，有些莫名奇怪的问题。

比如下面的代码：

#include <stdio.h>
#include <stdint.h>
#include <string.h>

#define ARRAY_SIZE(arr)        (sizeof(arr) / sizeof((arr)[0]))

int main(void)
{
char mac[6] = {0×80, 0×1E, 0×37, 0×1A, 0×3D, 0×7F};

int i = 0;
for(i = 0; i<ARRAY_SIZE(mac); i++) {
printf(”0x%X “, mac[i]);
}
printf(”\n”);

write1(mac, 6);
return 0;
}

void write1(unsigned char *buf, uint16_t buf_size)
{
int i = 0;
uint16_t cur_word = 0;

for (i = 0; i < buf_size; i += 2) {
cur_word = (uint16_t)((buf[i] <<8 ) | buf[i+1]);
printf(”0x%04X buf[i] 0x%02X  buf[i+1] 0x%02X\n”, cur_word, buf[i], buf[i+1]);
}
}

border@ubuntu:~$ uname -a
Linux ubuntu 2.6.24-21-generic #1 SMP Tue Oct 21 23:43:45 UTC 2008 i686 GNU/Linux
border@ubuntu:~$ ./hello
0xFFFFFF80 0×1E 0×37 0×1A 0×3D 0×7F
0×801E buf[i] 0×80  buf[i+1] 0×1E
0×371A buf[i] 0×37  buf[i+1] 0×1A
0×3D7F buf[i] 0×3D  buf[i+1] 0×7F

怎么打印结果不同, 在主函数里面第一个打印出来的是 0xFFFFFF80, 但是在write1函数里面就是正常的0×80了，但是你有可能说
是0x%x 和 0x%02x 的问题，于是程序改为:

char mac[6] = {0x80, 0x1E, 0x37, 0x1A, 0x3D, 0x7F};
int i = 0;
for(i = 0; iprintf("0x%02X ", mac[i]);
}
printf("\n");

就算是改为 %02X，也是输出0xFFFFFF80，和%x的结果一样。

但是如果把char mac[6] 改为 unsigned char mac[6] 主函数就没有问题。

在write1函数里面，如果你把参数unsigned char *buf 改为char *buf, 当大于0×7F的时候，也会溢出，是因为C 里面如果没有定义
类型符合的话默认为singned.

singned的取之范围是-128-127(0×80-0×7F), 所以当大于0×7F的时候会溢出。

unsigned 的取值范围是0-255(0-0xFF).

如果你要进行高低段位移的话，以后要定义为unsigned.

疑问:  为什么%02X输出的也是8个字节,而不是两个字节?

Bian Jiang
http://www.wifihack.net

–EOF–

本文参考: http://notes.jimlindley.com/2008/3/25/git-svn-that-works-for-me
作者: Jim Lindley

The canonical git-svn workflow that I’ve seen goes like this:
标准的git-svn工作流程参考这里:

[code lang="C"]
git svn clone
git checkout -b
…hack…hack…

git commit -a
git checkout master
git merge #NOTE: no need for –squash anymore
git svn rebase
git svn dcommit -e # -e will let you enter a commit message for SVN

[/code]

I’ve had more luck with the following workflow, when integrating changes via SVN from other team members:
我从团队的其他成员学到了更好的工作流程:

[code lang="C"]
# initial setup
git svn clone

# 99% of daily workflow
git checkout -b
…hack…hack…
git commit -a

# switch back to master, then rebase against
# any revisions in the svn repo
git checkout master
git svn rebase

# now that master is current with svn,
# sync working branch to local master
git checkout # These two are the added steps
git rebase master # which help prevent conflicts

# final upstream commit after rebasing
git checkout master
git svn rebase # one last check for new svn check ins
git merge
git svn dcommit -e

[/code]

The extra rebase step seems to do a better job of integrating your patches into the tree. Merge should do the same thing, if I’m reading the man pages right, but splitting the steps is more idiot proof (me-proof) this way.

It also keeps the master local branch from getting messy dealing with conflicts. Instead conflict is kept in the side working branch.

上面虽然很罗嗦但是做的好处在于，我们把所有的工作和从svn代码的合并都放在本地的分支上进行。这样就能保证本地主干与svn服务器进行同步，并且在本地主干没有任何修改。

更多有关git, git-svn,  git-reset 的文章:
1. git-svn workflow
2. An introduction to git-svn for Subversion/SVK users and deserters
3. Git reset in depth

2009.4.3
Bian Jiang
–EOF–