ubuntu 에서 /etc/resolv.conf 수정

Posted 2013.04.22 21:40

ubuntu에서 /etc/resolv.con를 직접 수정하면 안됨.


/etc/resolvconf/resolv.conf.d/base 파일을 수정하면 적용됨.


저작자 표시 비영리 변경 금지
신고

Network Manager 자동 시작 제거

 sudo update-rc.d -f NetworkManager remove

network-manager-gnome 을 제거



저작자 표시 비영리 변경 금지
신고

Boost socket performance on Linux

Posted 2011.10.25 14:21

http://www.ibm.com/developerworks/linux/library/l-hisock/index.html
신고

How to enable IP Forwarding in Linux

Posted 2009.10.13 11:43

http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/


How to enable IP Forwarding in Linux

By default any modern Linux distributions will have IP Forwarding disabled. This is normally a good idea, as most peoples will not need IP Forwarding, but if we are setting up a Linux router/gateway or maybe a VPN server (pptp or ipsec) or just a plain dial-in server then we will need to enable forwarding. This can be done in several ways that I will present bellow.

Check if IP Forwarding is enabled

We have to query the sysctl kernel value net.ipv4.ip_forward to see if forwarding is enabled or not:
Using sysctl:

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

or just checking out the value in the /proc system:

cat /proc/sys/net/ipv4/ip_forward
0

As we can see in both the above examples this was disabled (as show by the value 0).

Enable IP Forwarding on the fly

As with any sysctl kernel parameters we can change the value of net.ipv4.ip_forward on the fly (without rebooting the system):

sysctl -w net.ipv4.ip_forward=1

or

echo 1 > /proc/sys/net/ipv4/ip_forward

the setting is changed instantly; the result will not be preserved after rebooting the system.

Permanent setting using /etc/sysctl.conf

If we want to make this configuration permanent the best way to do it is using the file /etc/sysctl.conf where we can add a line containing net.ipv4.ip_forward = 1

/etc/sysctl.conf:
net.ipv4.ip_forward = 1

if you already have an entry net.ipv4.ip_forward with the value 0 you can change that 1.

To enable the changes made in sysctl.conf you will need to run the command:

sysctl -p /etc/sysctl.conf

On RedHat based systems this is also enabled when restarting the network service:

service network restart

and on Debian/Ubuntu systems this can be also done restarting the procps service:

/etc/init.d/procps.sh restart

Using distribution specific init scripts

Although the methods presented above should work just fine and you would not need any other method of doing this, I just wanted to note that there are also other methods to enable IP Forwarding specific to some Linux distributions.
For example Debian based distributions might use the setting:

/etc/network/options:
ip_forward=no

set it to yes and restart the network service.
Also RedHat distributions might set this using:

/etc/sysconfig/network:
FORWARD_IPV4=true

and again restart the network service.

Regardless the method you have used once you have completed this you can check it out using the same method shown above:

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
cat /proc/sys/net/ipv4/ip_forward
1

If the result is 1 then the Linux system will start forwarding IP packets even if they are not destined to any of its own network interfaces.

ps. I was setting up a VPN dial-in server when I wrote this post ;-) .

신고

tcpdump sh4 cross-compile

Posted 2009.05.22 19:09

먼저 libpcap 라이브러리를 사용하므로 libpcap-1.0.0 을 다운로드해서 컴파일한다.

configure를 아래와 같이 수정해 주어야 한다.

linux)
    { echo "$as_me:$LINENO: checking Linux kernel version" >&5
echo $ECHO_N "checking Linux kernel version... $ECHO_C" >&6; }
    if test "$cross_compiling" = yes; then
        if test "${ac_cv_linux_vers+set}" = set; then
  echo $ECHO_N "(cached) $ECHO_C" >&6
else
  #ac_cv_linux_vers=unknown
  ac_cv_linux_vers=2
fi

위와 같이 수정하지 않으면 아래와 같은 에러가 발생하면서 configure가 중지됨.

checking whether ether_hostton is declared... yes
checking if --disable-protochain option is specified... enabled
checking packet capture type... linux
checking Linux kernel version... unknown
configure: error: cannot determine linux version when cross-compiling

위와 같이 수정한 후, 아래와 같이 configure를 실행하고 make 하면 libpcap.a 가 생성되며,
공유라이브러리는 생성되지 않음.

CC=sh4-weldk-linux-gcc ./configure --target=sh4 --host=i686-pc-linux-gnu --with-pcap=linux

===============================================================================================

다음으로 tcpdump를 다운로드 받아서 libpcap 처럼 configure를 수정한다.

CC=sh4-weldk-linux-gcc ./configure --target=sh4 --host=i686-pc-linux-gnu --disable-ipv6

위와 같이 configure를 실행한 후에, make를 실행하면 아래와 같은 컴파일 에러가 발생한다.

[root@localhost tcpdump-4.0.0]# make
sh4-weldk-linux-gcc -O2 -DHAVE_CONFIG_H  -I./../libpcap-1.0.0  -I/usr/include -I./missing  -D_U_="__attribute__((unused))" -I. -I./../libpcap-1.0.0  -I/usr/include -I./missing -c ./addrtoname.c
/tmp/cccsSz4g.s: Assembler messages:
/tmp/cccsSz4g.s:407: Error: unknown opcode
/tmp/cccsSz4g.s:514: Error: unknown opcode
/tmp/cccsSz4g.s:587: Error: unknown opcode
/tmp/cccsSz4g.s:587: Error: unknown opcode
/tmp/cccsSz4g.s:587: Error: unknown opcode
/tmp/cccsSz4g.s:2132: Error: unknown opcode
/tmp/cccsSz4g.s:2271: Error: unknown opcode
/tmp/cccsSz4g.s:2293: Error: unknown opcode
/tmp/cccsSz4g.s:2327: Error: unknown opcode
/tmp/cccsSz4g.s:2660: Error: unknown opcode
/tmp/cccsSz4g.s:2681: Error: unknown opcode
make: *** [addrtoname.o] Error 1
[root@localhost tcpdump-4.0.0]#

위의 에러를 없애기 위해서 Makefile을 수정해야 하는데, -O2 옵션을 빼주면 된다.

#
# You shouldn't need to edit anything below here.
#

CC = sh4-weldk-linux-gcc
PROG = tcpdump
# CCOPT = -O2 <-- 수정된 부분
INCLS = -I. -I./../libpcap-1.0.0  -I/usr/include -I$(srcdir)/missing
DEFS = -DHAVE_CONFIG_H  -I./../libpcap-1.0.0  -I/usr/include -I$(srcdir)/missing  -D_U_="__attribute__((unused))"

수정한 후에 컴파일을 하면 아래와 같은 에러가 발생한다.

sh4-weldk-linux-gcc  -DHAVE_CONFIG_H  -I./../libpcap-1.0.0  -I/usr/include -I./missing  -D_U_="__attribute__((unused))" -I. -I./../libpcap-1.0.0  -I/usr/include -I./missing -c ./print-esp.c
./print-esp.c:75: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘*’ token
./print-esp.c: In function ‘esp_print_decode_onesecret’:
./print-esp.c:225: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
./print-esp.c:225: error: ‘evp’ undeclared (first use in this function)
./print-esp.c:225: error: (Each undeclared identifier is reported only once
./print-esp.c:225: error: for each function it appears in.)
./print-esp.c:255: error: ‘struct sa_list’ has no member named ‘evp’
./print-esp.c:256: error: ‘struct sa_list’ has no member named ‘authlen’
./print-esp.c:257: error: ‘struct sa_list’ has no member named ‘ivlen’
./print-esp.c:261: error: ‘struct sa_list’ has no member named ‘evp’
./print-esp.c:262: error: ‘struct sa_list’ has no member named ‘authlen’
./print-esp.c:263: error: ‘struct sa_list’ has no member named ‘ivlen’
./print-esp.c:283: error: ‘struct sa_list’ has no member named ‘secret’
./print-esp.c:284: error: ‘struct sa_list’ has no member named ‘secretlen’
./print-esp.c:288: error: ‘struct sa_list’ has no member named ‘secret’
./print-esp.c:289: error: ‘struct sa_list’ has no member named ‘secret’
./print-esp.c:290: error: ‘struct sa_list’ has no member named ‘secretlen’
./print-esp.c:292: error: ‘struct sa_list’ has no member named ‘secret’
./print-esp.c:292: error: ‘struct sa_list’ has no member named ‘secret’
./print-esp.c:293: error: ‘struct sa_list’ has no member named ‘secretlen’
./print-esp.c:293: error: ‘struct sa_list’ has no member named ‘secret’
./print-esp.c: In function ‘esp_init’:
./print-esp.c:323: error: ‘SN_des_ede3_cbc’ undeclared (first use in this function)
./print-esp.c: In function ‘esp_print’:
./print-esp.c:360: error: ‘EVP_CIPHER_CTX’ undeclared (first use in this function)
./print-esp.c:360: error: expected ‘;’ before ‘ctx’
./print-esp.c:469: error: ‘struct sa_list’ has no member named ‘ivlen’
./print-esp.c:470: error: ‘struct sa_list’ has no member named ‘secret’
./print-esp.c:471: error: ‘struct sa_list’ has no member named ‘secretlen’
./print-esp.c:472: error: ‘struct sa_list’ has no member named ‘authlen’
./print-esp.c:474: error: ‘struct sa_list’ has no member named ‘evp’
./print-esp.c:475: error: ‘ctx’ undeclared (first use in this function)
./print-esp.c:476: error: ‘struct sa_list’ has no member named ‘evp’
make: *** [print-esp.o] Error 1

위의 에러를 Skip 하기 위해 config.h에서 HAVE_LIBCRYPT를 comment out 한다. 0으로 설정하면 안됨.

/* Define to 1 if you have the `crypto' library (-lcrypto). */
//#define HAVE_LIBCRYPTO 1

또한 소스를 수정해야 한다.  print-enc.c에 ip6_print를 사용하는 부분이 있는데, #ifdef INET6로 감싸줘야 한다.

81라인
#ifdef INET6
  ip6_print(p, length);
#endif  

신고

'Research > Network' 카테고리의 다른 글

Boost socket performance on Linux  (0) 2011.10.25
How to enable IP Forwarding in Linux  (0) 2009.10.13
tcpdump sh4 cross-compile  (0) 2009.05.22
tcp packet을 받을때 커널의 흐름  (0) 2008.11.26
Network performance test  (0) 2005.09.20
TCP/IP 동영상  (0) 2002.12.04

출처: http://www.tldp.org/HOWTO/KernelAnalysis-HOWTO-8.html


We'll see now an example of what happens when we send a TCP packet to Linux, starting from ''netif_rx [net/core/dev.c]'' call.

Interrupt management: "netif_rx"

|netif_rx
|__skb_queue_tail
|qlen++
|* simple pointer insertion *
|cpu_raise_softirq
|softirq_active(cpu) |= (1 << NET_RX_SOFTIRQ) // set bit NET_RX_SOFTIRQ in the BH vector

Functions:

  • __skb_queue_tail [include/linux/skbuff.h]
  • cpu_raise_softirq [kernel/softirq.c]

Post Interrupt management: "net_rx_action"

Once IRQ interaction is ended, we need to follow the next part of the frame life and examine what NET_RX_SOFTIRQ does.

We will next call ''net_rx_action [net/core/dev.c]'' according to "net_dev_init [net/core/dev.c]".

|net_rx_action
|skb = __skb_dequeue (the exact opposite of __skb_queue_tail)
|for (ptype = first_protocol; ptype < max_protocol; ptype++) // Determine
|if (skb->protocol == ptype) // what is the network protocol
|ptype->func -> ip_rcv // according to ''struct ip_packet_type [net/ipv4/ip_output.c]''

**** NOW WE KNOW THAT PACKET IS IP ****
|ip_rcv
|NF_HOOK (ip_rcv_finish)
|ip_route_input // search from routing table to determine function to call
|skb->dst->input -> ip_local_deliver // according to previous routing table check, destination is local machine
|ip_defrag // reassembles IP fragments
|NF_HOOK (ip_local_deliver_finish)
|ipprot->handler -> tcp_v4_rcv // according to ''tcp_protocol [include/net/protocol.c]''

**** NOW WE KNOW THAT PACKET IS TCP ****
|tcp_v4_rcv
|sk = __tcp_v4_lookup
|tcp_v4_do_rcv
|switch(sk->state)

*** Packet can be sent to the task which uses relative socket ***
|case TCP_ESTABLISHED:
|tcp_rcv_established
|__skb_queue_tail // enqueue packet to socket
|sk->data_ready -> sock_def_readable
|wake_up_interruptible


*** Packet has still to be handshaked by 3-way TCP handshake ***
|case TCP_LISTEN:
|tcp_v4_hnd_req
|tcp_v4_search_req
|tcp_check_req
|syn_recv_sock -> tcp_v4_syn_recv_sock
|__tcp_v4_lookup_established
|tcp_rcv_state_process

*** 3-Way TCP Handshake ***
|switch(sk->state)
|case TCP_LISTEN: // We received SYN
|conn_request -> tcp_v4_conn_request
|tcp_v4_send_synack // Send SYN + ACK
|tcp_v4_synq_add // set SYN state
|case TCP_SYN_SENT: // we received SYN + ACK
|tcp_rcv_synsent_state_process
tcp_set_state(TCP_ESTABLISHED)
|tcp_send_ack
|tcp_transmit_skb
|queue_xmit -> ip_queue_xmit
|ip_queue_xmit2
|skb->dst->output
|case TCP_SYN_RECV: // We received ACK
|if (ACK)
|tcp_set_state(TCP_ESTABLISHED)

Functions can be found under:

  • net_rx_action [net/core/dev.c]
  • __skb_dequeue [include/linux/skbuff.h]
  • ip_rcv [net/ipv4/ip_input.c]
  • NF_HOOK -> nf_hook_slow [net/core/netfilter.c]
  • ip_rcv_finish [net/ipv4/ip_input.c]
  • ip_route_input [net/ipv4/route.c]
  • ip_local_deliver [net/ipv4/ip_input.c]
  • ip_defrag [net/ipv4/ip_fragment.c]
  • ip_local_deliver_finish [net/ipv4/ip_input.c]
  • tcp_v4_rcv [net/ipv4/tcp_ipv4.c]
  • __tcp_v4_lookup
  • tcp_v4_do_rcv
  • tcp_rcv_established [net/ipv4/tcp_input.c]
  • __skb_queue_tail [include/linux/skbuff.h]
  • sock_def_readable [net/core/sock.c]
  • wake_up_interruptible [include/linux/sched.h]
  • tcp_v4_hnd_req [net/ipv4/tcp_ipv4.c]
  • tcp_v4_search_req
  • tcp_check_req
  • tcp_v4_syn_recv_sock
  • __tcp_v4_lookup_established
  • tcp_rcv_state_process [net/ipv4/tcp_input.c]
  • tcp_v4_conn_request [net/ipv4/tcp_ipv4.c]
  • tcp_v4_send_synack
  • tcp_v4_synq_add
  • tcp_rcv_synsent_state_process [net/ipv4/tcp_input.c]
  • tcp_set_state [include/net/tcp.h]
  • tcp_send_ack [net/ipv4/tcp_output.c]

Description:

  • First we determine protocol type (IP, then TCP)
  • NF_HOOK (function) is a wrapper routine that first manages the network filter (for example firewall), then it calls ''function''.
  • After we manage 3-way TCP Handshake which consists of:
신고

'Research > Network' 카테고리의 다른 글

How to enable IP Forwarding in Linux  (0) 2009.10.13
tcpdump sh4 cross-compile  (0) 2009.05.22
tcp packet을 받을때 커널의 흐름  (0) 2008.11.26
Network performance test  (0) 2005.09.20
TCP/IP 동영상  (0) 2002.12.04
Lookahead buffer  (0) 2002.12.04

Network performance test

Posted 2005.09.20 20:38

ttcp/nttcp/nuttcp/iperf versions

ttcp was one of the first TCP throughput testing tools ever written. It was created by Mike Muuss at BRL to compare the performance of TCP stacks by U.C. Berkeley and BBN to help DARPA decide which version to place in the first BSD Unix release (Berkeley won). The name stands for "Test TCP", but it also supports UDP testing. Many variations have since been created with different defaults, new options, ports to new systems, etc.

What does the reported data rate really mean?

All variations of ttcp/iperf report payload or user data rates, i.e. no overhead bytes from headers (TCP, UDP, IP, etc.) are included in the reported data rates. When comparing to "line" rates or "peak" rates, it is important to consider all of this overhead. It is also important to understand what the tools mean by "K" or "M" bits or bytes per second. Versions of the tools differ on this point.

Computer memory is measured in powers of two, e.g. 1 KB = 2^10 = 1024 bytes; 1 MB = 2^20 = 1024*1024 = 1048576 bytes. Data communication rates however should always be stated in simple bits per second. For example "100 megabit ethernet" can send exactly 100,000,000 bits per second.

    K and M in ttcp/nttcp/iperf
    • ttcp original: K = 1024 (M is not used)
    • nttcp: K = 1024, M = 1000*1024
    • iperf 1.1.1 and earlier: K = 1024, M = 1024*1024
    • iperf 1.2 and above: K=1000, M=1000000
    • nuttcp: K=1000, M=1000000
Thus for some early tools, the reported K bits per second should be multipled by 1.024 to get the actual kilobits per second payload data rate. Reported M bits per second should be multipled by 1.024 for nttcp and 1.048576 for iperf to get the payload data rate in millions of bits per second. Iperf 1.2 and above and nuttcp correctly report bits per second rates in power of ten.

Differnet Versions

ttcp original

(source code)
RCSid[] = "@(#)$Header: ttcp.c,v 1.10 87/09/02 23:26:36 mike Exp $ (BRL)"
Usage: ttcp -t [-options] host out
	-l##	length of network read buf (default 1024)
	-s	sink (discard) all data from network
	-p##	port number to listen at (default 2000)
	-B	Only output full blocks, as specified in -l## (for TAR)
	-u	use UDP instead of TCP
Example run:
% ttcp -r -s
ttcp-r: nbuf=1024, buflen=1024, port=2000
ttcp-r: socket
ttcp-r: accept
ttcp-r: 0.0user 0.5sys 0:10real 5% 0i+0d 0maxrss 0+0pf 0+0csw
ttcp-r: 74891264 bytes processed
ttcp-r:      0.54 CPU sec  =    135437 KB/cpu sec,  1.0835e+06 Kbits/cpu sec
ttcp-r:    10.067 real sec =   7264.92 KB/real sec,   58119.3 Kbits/sec
It is also worth noting that the "bytes processed" number can wrap for large data transfers.

nttcp

(source code)

Created by someone at Silicon Graphics (SGI), it added the important option (-w) to set the transmit and receive window size (actually socket buffer sizes, which indirectly set the window size). It also changed several things:

  • changed default nbuf (-n) from 1024 to 2048
  • changed default buflen (-l) from 1024 to 65536
  • changed default port (-p) from 2000 to 5001
  • added window size (-w) option
  • added TCP nodelay (-D) option
  • reversed the meaning of (-s) source/sink option!

The default buffer length increase to 65536 was probably an attempt to maximize performance by reducing the number of write system calls. I have found however that on modern systems larger buffers are not always faster because they may not fit in cache memory as well. Somewhere around 8kB seems like a good value in my experience for todays hardware.

The change in default port and the meaning of -s is unfortunate. At least the author changed the program name. Others however have created "ttcp" programs that also have these changes. iperf and nuttcp continued nttcp's use of port 5001.

Usage: ttcp -t [-options] host [ out]
	-l##	length of network read buf (default 8192)
	-s	don't sink (discard): prints all data from network to stdout
	-p##	port number to listen at (default 5001)
	-B	Only output full blocks, as specified in -l## (for TAR)
	-u	use UDP instead of TCP
Example run:
% ./nttcp -r
ttcp-r: buflen=65536, nbuf=2048, port=5001 tcp
ttcp-r: socket
ttcp-r: accept from 127.0.0.1
send window size = 65535
receive window size = 65535
ttcp-r: 455426048 bytes in 10.05 real seconds = 44243.41 KB/sec = 353.9473 Mb/s
ttcp-r: 55550 I/O calls, msec/call = 0.19, calls/sec = 5526.05
ttcp-r: 0.0user 2.5sys 0:10real 25% 0i+0d 0maxrss 0+14pf 0+0csw

nuttcp

ftp://ftp.lcp.nrl.navy.mil/pub/nuttcp/

One of the best! Highly recommended. The author calls it n-u-t-t-c-p, but many of us affectionately call it nut-c-p. nuttcp can run as a server and passes all output back to the client side, so you don't need an account on the server side to see the results.

Usage: nuttcp or nuttcp -h      prints this usage info
Usage: nuttcp -V                prints version info
Usage: nuttcp -xt [-m] host     forward and reverse traceroute to/from server
Usage (transmitter): nuttcp -t [-options] host [3rd-party] [ out]
        -4      Use IPv4
        -6      Use IPv6
        -l##    length of network read buf (default 8192/udp, 65536/tcp)
        -s      don't sink (discard): prints all data from network to stdout
        -n##    number of bufs for server to write to network (default 2048)
        -w##    receiver window size in KB (or (m|M)B or (g|G)B)
        -ws##   server transmit window size in KB (or (m|M)B or (g|G)B)
        -wb     braindead Solaris 2.8 (sets both xmit and rcv windows)
        -p##    port number to listen at (default 5001)
        -P##    port number for control connection (default 5000)
        -B      Only output full blocks, as specified in -l## (for TAR)
        -u      use UDP instead of TCP
        -m##    use multicast with specified TTL instead of unicast (UDP)
        -N##    number of streams (starting at port number), implies -B
        -R##    server transmit rate limit in Kbps (or (m|M)bps or (g|G)bps)
        -T##    server transmit timeout in seconds (or (m|M)inutes or (h|H)ours)
        -i##    client interval reporting in seconds (or (m|M)inutes)
        -Ixxx   identifier for nuttcp output (max of 40 characters)
        -F      flip option to reverse direction of data connection open
        -xP##   set nuttcp process priority (must be root)
        -d      set TCP SO_DEBUG option on data socket
        -v[v]   verbose [or very verbose] output
        -b      brief output (default)
Usage (server): nuttcp -S [-options]
                note server mode excludes use of -s
        -4      Use IPv4 (default)
        -6      Use IPv6
        -1      oneshot server mode (implied with inetd/xinetd), implies -S
        -P##    port number for server connection (default 5000)
                note don't use with inetd/xinetd (use services file instead)
        -xP##   set nuttcp process priority (must be root)
        --no3rdparty don't allow 3rd party capability
        --nofork     don't fork server
Format options:
        -fxmitstats     also give transmitter stats (MB) with -i (UDP only)
        -frunningtotal  also give cumulative stats on interval reports
        -f-drops        don't give packet drop info on brief output (UDP)
        -f-percentloss  don't give %loss info on brief output (UDP)
        -fparse         generate key=value parsable output

iperf

http://dast.nlanr.net/Projects/Iperf/

% iperf -v
iperf version 1.1.1 (23 Feb 2000) pthreads
Example run:
% iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  6] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 3639
[ ID] Interval       Transfer     Bandwidth
[  6]  0.0-10.0 sec   421 MBytes   336 Mbits/sec

P. Dykstra, phil@sd.wareonearth.com, March 2001 (update March 2004)
신고

'Research > Network' 카테고리의 다른 글

How to enable IP Forwarding in Linux  (0) 2009.10.13
tcpdump sh4 cross-compile  (0) 2009.05.22
tcp packet을 받을때 커널의 흐름  (0) 2008.11.26
Network performance test  (0) 2005.09.20
TCP/IP 동영상  (0) 2002.12.04
Lookahead buffer  (0) 2002.12.04

TCP/IP 동영상

Posted 2002.12.04 13:33
<출처>해커스랩
신고

'Research > Network' 카테고리의 다른 글

How to enable IP Forwarding in Linux  (0) 2009.10.13
tcpdump sh4 cross-compile  (0) 2009.05.22
tcp packet을 받을때 커널의 흐름  (0) 2008.11.26
Network performance test  (0) 2005.09.20
TCP/IP 동영상  (0) 2002.12.04
Lookahead buffer  (0) 2002.12.04

Lookahead buffer

Posted 2002.12.04 13:29
All messages from thread
Message 1 in thread
보낸 이:An Jung Sun (crete@garnets.com)
제목:What is a meaning of "Lookahead"?
뉴스 그룹:comp.os.ms-windows.programmer.nt.kernel-mode
View this article only
날짜:1998/08/03


hi..
I want to know that meaning of "lookahead".
I am developing the NDIS driver....
Can anyone help me?
Message 2 in thread
보낸 이:David (qqqq@xxx.yyy.zzz)
제목:Re: What is a meaning of "Lookahead"?
뉴스 그룹:comp.os.ms-windows.programmer.nt.kernel-mode
View this article only
날짜:1998/08/03


"An Jung Sun" <crete@garnets.com> writes:
>
> I want to know that meaning of "lookahead".
> I am developing the NDIS driver....
Packets come into a protocol (or intermediate) driver through one of two
callback routines.
In your ProtocolReceivePacket callback function, you are given a
complete packet.  If the routine completely handles the packet (or
rejects it), it should return zero - telling the lower-layer miniport
that it is OK to free the packet.  If it returns non-zero, then it is
telling NDIS that it needs to hold the packet for a while - the
lower-layer miniport will free the packet when NdisReturnPackets is
called that many times.  (eg. if you return 5, you must call
NdisReturnPackets 5 times.)
The ProtocolReceive callback doesn't work like this.  In
ProtocolReceive, you are not given an entire packet.  Instead, you get
the packet's header, and some of the packet's data, along with the size
of the complete packet.  The data you are given is the "lookahead"
buffer.  The header and lookahead buffers are freed as soon as
ProtocolReceive returns.
If the lookahead buffer contains the entire packet (if its size is equal
to the total size), then you have the entire packet.  If not, then you
must call NdisTransferData to get the rest of it.  Either way, if you
want to hold on to the data beyond the scope of the ProtocolReceive
callback, you must create a new packet from the header and data blocks
you are given.  When you're finished with your copy, just free it - you
don't tell the underlying miniport in this situation.
You must implement ProtocolReceive in your protocol driver.  You should
implement ProtocolReceivePacket as well, in order to improve
performance.
-- David
Message 3 in thread
보낸 이:Dean Henkel (henkel@us.ibm.com)
제목:Re: What is a meaning of "Lookahead"?
뉴스 그룹:comp.os.ms-windows.programmer.nt.kernel-mode
View this article only
날짜:1998/08/18


David I pose this question to you because I'm sure you know the answer.
PacketRecievePacket will check to see if a pending ProtocolRecieve has
occurred. If it has, it will transfer the data. If not it throws it away.
My questions are:
How do I buffer the data in ProtocolRecievePacket if there is no outstanding
PacketReceiveIndicate call?
When the PacketlRecieiveIndicate call does occur how do I transfer this
buffered data into the user level buffer?
Would I be better off rejecting the packet even if it all is there, and
accepting it on a later PacketRead call?
If yes what if 2 packets come in, will the lower layer buffer them properly?
This driver is bound to a Ethernet and Token Ring driver. Everything works
except for the buffering of packets.
Here's the code snippet.
Thanks, hope you can help.
NTSTATUS
PacketRead(
    IN PDEVICE_OBJECT DeviceObject,
    IN PIRP Irp
    )
{
    POPEN_INSTANCE      Open;
    PIO_STACK_LOCATION  IrpSp;
    PNDIS_PACKET        pPacket;
    NDIS_STATUS         Status;
    IF_LOUD(DbgPrint("Packet: Readn");)
    IrpSp = IoGetCurrentIrpStackLocation(Irp);
    Open=IrpSp->FileObject->FsContext;
    //
    //  See if the buffer is atleast big enough to hold the
    //  ethernet header
    //
    if (IrpSp->Parameters.Read.Length < ETHERNET_HEADER_LENGTH) {
        Irp->IoStatus.Status = STATUS_UNSUCCESSFUL;
        return STATUS_UNSUCCESSFUL;
    }
문서 전부 보기... (254줄 이상)

Message 4 in thread
보낸 이:David (qqqq@xxx.yyy.zzz)
제목:Re: What is a meaning of "Lookahead"?
뉴스 그룹:comp.os.ms-windows.programmer.nt.kernel-mode
View this article only
날짜:1998/08/19



Dean Henkel <henkel@us.ibm.com> writes:
>
> David I pose this question to you because I'm sure you know the
> answer.
Don't be so sure.  But we'll find out...
> PacketRecievePacket will check to see if a pending ProtocolRecieve has
> occurred. If it has, it will transfer the data. If not it throws it
> away.
What is "PacketRecievePacket"?  It's not an NDIS callback function, and
it's not in the code you posted.  I'll assume it's one of your
functions...
> My questions are:
> How do I buffer the data in ProtocolRecievePacket if there is no
> outstanding PacketReceiveIndicate call?
You're confused here.  ProtocolReceive and ProtocolReceivePacket are
never both called for a single packet.  One or the other, depending on
what the underlying miniport is using to indicate the packet to you.
If ProtocolReceivePacket is called, then you have the entire packet.  If
you return non-zero, then the packet will remain valid until you call
NdisReturnPackets.  If you return zero, the packet becomes invalid as
soon as the ProtocolReceivePacket function returns.
If ProtocolReceve is called, then you don't have a packet.  You have
some buffers (header and lookahead) that become invalid as soon as the
function returns.  If you want to hold on to the data beyond the scope
of the function, you must copy it to some other piece of memory.
There isn't a ways to look for outstanding indications.  Your callback
function(s) get called by NDIS when the underlying miniport indicates
packets to you.
> When the PacketlRecieiveIndicate call does occur how do I transfer
> this buffered data into the user level buffer?
I can't help you here.  I haven't written a protocol driver.  I'm
working with an intermediate driver.  I take the buffered data,
construct a new NDIS_PACKET, and indicate that data to the protocol
attached to my driver's upper-edge.
> Would I be better off rejecting the packet even if it all is there,
> and accepting it on a later PacketRead call?
If you reject it, it's gone.  It may be sent to some other protocol,

신고

'Research > Network' 카테고리의 다른 글

How to enable IP Forwarding in Linux  (0) 2009.10.13
tcpdump sh4 cross-compile  (0) 2009.05.22
tcp packet을 받을때 커널의 흐름  (0) 2008.11.26
Network performance test  (0) 2005.09.20
TCP/IP 동영상  (0) 2002.12.04
Lookahead buffer  (0) 2002.12.04

티스토리 툴바