Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 03 Jun 2002 08:18:30 -0700
From:      Lars Eggert <larse@ISI.EDU>
To:        Archie Cobbs <archie@dellroad.org>
Cc:        net@FreeBSD.ORG
Subject:   Re: netgraph documentation?
Message-ID:  <3CFB88C6.4070407@isi.edu>
References:  <200205312337.g4VNbbs03438@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]
Archie Cobbs wrote:
>>/usr/sbin/ngctl mkpeer iface dummy inet
>>/usr/sbin/ngctl mkpeer ng3: ksocket inet inet/stream/tcp
>>/usr/sbin/ngctl msg ng3:inet bind inet/10.0.0.1:50505
>>/usr/sbin/ngctl msg ng3:inet listen 1
>>ngctl: send msg: Operation not supported by device
>>
>>	2. Why can't I listen on a ksocket?
> 
> What you are doing is correct, I don't know why you are getting
> that error. The error is coming from solisten().
> 
> However, when I try this the listen operation does actually
> succeed as witnessed by 'netstat -na -f inet'.

You're right, I see:

[root@hbo: ~larse] netstat -na -f inet
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0      0  127.0.0.1.50505        *.*                    LISTEN

So I ignore the error for now, and make the TCP tunnel as follows:

Server:
	/usr/sbin/ngctl mkpeer iface dummy inet
	/sbin/ifconfig ng0 10.10.10.1 10.10.10.2
	/usr/sbin/ngctl mkpeer ng0: ksocket inet inet/stream/tcp
	/usr/sbin/ngctl msg ng0:inet bind inet/127.0.0.1:50505
	/usr/sbin/ngctl msg ng0:inet listen 1
	ngctl: send msg: Operation not supported by device

Client:
	/usr/sbin/ngctl mkpeer iface dummy inet
	/sbin/ifconfig ng1 10.10.10.2 10.10.10.1
	/usr/sbin/ngctl mkpeer ng1: ksocket inet inet/stream/tcp
	/usr/sbin/ngctl msg ng1:inet bind inet/127.0.0.1:50506
	/usr/sbin/ngctl msg ng1:inet connect inet/127.0.0.1:50505
	ngctl: send msg: Operation now in progress

A tcpdump on lo0 shows the 3-way handshake suceeding:

[root@hbo: ~larse] tcpdump -i lo0 port 50505
tcpdump: listening on lo0
08:11:29.013658 loopback.50506 > loopback.50505: S 
2787661608:2787661608(0) win 65535 <mss 16344,nop,wscale 
1,nop,nop,timestamp 14010458 0,nop,nop,cc 383> (DF)
08:11:29.013710 loopback.50505 > loopback.50506: S 
1751674938:1751674938(0) ack 2787661609 win 65535 <mss 16344,nop,wscale 
1,nop,nop,timestamp 14010458 14010458,nop,nop,cc 384,nop,nop,ccecho 383>
08:11:29.013754 loopback.50506 > loopback.50505: . ack 1 win 32767 
<nop,nop,timestamp 14010458 14010458,nop,nop,cc 383> (DF)

Pinging 10.10.10.2 results in:

[root@hbo: ~larse] ping 10.10.10.2 
         PING 10.10.10.2 (10.10.10.2): 56 data bytes
ping: sendto: Socket is not connected
ping: sendto: Socket is not connected
ping: sendto: Socket is not connected
^C
--- 10.10.10.2 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

A tcpdump on lo0 shows no packets.

Pinging 10.10.10.1 results in:

[root@hbo: ~larse] ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 56 data bytes
^C
--- 10.10.10.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

This is captures by tcpdump on lo0:

[root@hbo: ~larse] tcpdump -i lo0 port 50505
tcpdump: listening on lo0
08:15:21.228886 loopback.50506 > loopback.50505: P 
2787661609:2787661693(84) ack 1751674939 win 32767 <nop,nop,timestamp 
14033679 14010458,nop,nop,cc 383> (DF)
08:15:21.323163 loopback.50505 > loopback.50506: . ack 84 win 32725 
<nop,nop,timestamp 14033689 14033679,nop,nop,cc 384> (DF)
08:15:22.233135 loopback.50506 > loopback.50505: P 84:168(84) ack 1 win 
32767 <nop,nop,timestamp 14033780 14033689,nop,nop,cc 383> (DF)
08:15:22.333089 loopback.50505 > loopback.50506: . ack 168 win 32683 
<nop,nop,timestamp 14033790 14033780,nop,nop,cc 384> (DF)
08:15:23.243144 loopback.50506 > loopback.50505: P 168:252(84) ack 1 win 
32767 <nop,nop,timestamp 14033881 14033790,nop,nop,cc 383> (DF)
08:15:23.343084 loopback.50505 > loopback.50506: . ack 252 win 32641 
<nop,nop,timestamp 14033891 14033881,nop,nop,cc 384> (DF)

I don't know enough about the netgraph internals to debug this further 
myself, but I'd be more than happy to do any tests that'd help you or 
someone else look into this. (I should probably mention that I'm using 
4.5-RELEASE.)

Thanks,
Lars
-- 
Lars Eggert <larse@isi.edu>           USC Information Sciences Institute

[-- Attachment #2 --]
0	*H
010	+0	*H
00G0
	*H
010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.300
010824164000Z
020824164000Z0T10
UEggert1
0U*Lars10ULars Eggert10	*H
	
larse@isi.edu00
	*H
0|\Pw v~~FDooӦA\-	 Cˀ4.)&{肋,z(ܷر߈T7_'txGH^tt/ҹB8%t<#ֲNV0T0*+e!000L2uMyffBNUbNJJcdZ2s0U0
larse@isi.edu0U00
	*H
aJPMՒ]cѭC+kS+wZ1gY",YT41
j6:~℩D~Kؚ‡l=u(ՎM?cF7@}T00G0
	*H
010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.300
010824164000Z
020824164000Z0T10
UEggert1
0U*Lars10ULars Eggert10	*H
	
larse@isi.edu00
	*H
0|\Pw v~~FDooӦA\-	 Cˀ4.)&{肋,z(ܷر߈T7_'txGH^tt/ҹB8%t<#ֲNV0T0*+e!000L2uMyffBNUbNJJcdZ2s0U0
larse@isi.edu0U00
	*H
aJPMՒ]cѭC+kS+wZ1gY",YT41
j6:~℩D~Kؚ‡l=u(ՎM?cF7@}T080fErtcvE.0
	*H
010	UZA10UWestern Cape10U	Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0)	*H
	personal-freemail@thawte.com0
000830000000Z
040827235959Z010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.3000
	*H
032c	%E>nx'gڈD)c5*mp<ܮto034qmOe
KaU5u'rװ|CBPQ<9TIf-	kiN0L0)U"0 010UPrivateLabel1-2970U00U0
	*H
1KG]qSl]y=&b""I'{9$
*8PUl
LGlX1B	li+@]jy.%݊
Z<D&iHΥbb100010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.30G0	+a0	*H
	1	*H
0	*H
	1
020603151830Z0#	*H
	1sj[ K[v)>m$qz0R	*H
	1E0C0
*H
0*H
0
*H
@0+0
*H
(0*H
	1010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.30G0
	*H
2\Q6{qLT@e5B_7psrk&!Ni&_3Ä)XjnrvѰd'"$'AJ-?p1h]ܱ]#ƹ

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFB88C6.4070407>