Planet FreeBSD

May 12, 2008

  Edwin Groothuis (edwin)  [stats, website]

FreeBSD IPv6 Divert socket adventures (2)

A small update:

  • Dr. Goto has replied. It seems that I contacted him at the beginning on the Golden Week, a week in Japan with a lot of free days so that was the reason it took longer. His patches are against 5.2.1 and applied without problems but didn't compile. But it gave me some good hints.
  • Three kernel panics later I was told by Bruce M Simpson to use Qemu for kernel development work. Two days later I have it up and running. Works nice, I have it booting via PXE and the disks are mounted via NFS. I can boot in several FreeBSD versions but not into 5.2.1 because it hangs just before starting the userland. So far for my reference platform...
  • I have copied sys/src/netinet/ip_divert.c to sys/src/netinet/ip6_divert.c and modified all IPv4 functions into their IPv6 equivalents. Also added IP_PROTO_SPACERS to in6_proto.h. And finally when I open a socket with PF_INET6 and SOCK_RAW and IPPROTO_DIVERT, I get a proper socket: 
    nat6to4d 2578 root 3u IPv6 0xc1df8ec4 0t0 DIVERT *:8666
nat6to4d 2578 root 4u IPv4 0xc1dfaec4 0t0 DIVERT *:8664
    sockstat still doesn't show it though...
  • Internally in ip6_divert.c, instead of abusing the sin_zero[] fields in struct sockaddr_in I have created the new sockaddr type struct sockaddr_div: 
    struct sockaddr_div { uint8_t div_len; sa_family_t div_family; /* AF_INET / AF_INET6 */ in_port_t div_cookie; /* was: sin_port */ char div_iface[8]; struct in6_addr div6_addr; /* IPv6 address */ struct in_addr div4_addr; /* IPv4 address */
};
    This could / should be also used in the normal ip_divert code.

So what works and what doesn't?

  • IPv6 packet goes from divert to the nat6to4 daemon. Yay!
    (TCP SYN packet from IPv6 host to the IPv6 address of the machine with the nat6to4 daemon)
  • IPv4 packet goes from the nat6to4 daemon to divert. Yay!
    (TCP SYN packet from the IPv4 address of the machine with the nat6to4 daemon to the IPv4 host. Trivia: Why do you need to recalculate the TCP checksum when you haven't changed the TCP header and TCP payload?)
  • IPv4 packet goes from divert to the nat6to4 daemon. Yay!
    (TCP SYN-ACK packet from IPv4 host to the IPv4 address of the machine with the nat6to4 daemon)
  • IPv6 packet does not go from the nat6to4 daemon into divert. What?!?!?
I'm not sure what goes wrong here: sendto() says that it is accepted, but the packet is expected to end up on the div6_send() function but it doesn't end up there. For some reason. Which is kind of annoying. Robert Watson suggested to check the GDB debugger what happens in the sendto() call.

But that is an adventure for later when I have some spare time again... work and two kids, that doesn't leave much time adventures like this (except between 22:00 and 01:00 which is very bad for everybody)

Posted on May 12, 2008 01:00 AM

 

May 07, 2008

  Martin Wilke (miwi)  [stats, website]

First Screenshots of Q 4.4 and KDE 4.1 (alpha)

Last week the KDE Team released KDE 4.1 Alpha, I’ve sent a proposal to the FreeBSD-KDE mailing list to update QT4 to 4.4 RC, and to start to work with KDE 4.1 Alpha, and have explained why we should do that. My request was accept by some peoples, via ML or Private mail/irc discussion. David told me Qt 4.4 RELEASE [...]

Posted on May 07, 2008 11:47 PM

 

May 06, 2008

  Edwin Groothuis (edwin)  [stats, website]

FreeBSD IPv6 Divert socket adventures

This whole IPv6 Divert idea seems to be a little bit optimistic now. As all new technology (I wouldn't call IPv6 new technology, but still) not everything you have available now is supported in it.

So, how far did we get?

  • FreeBSD's ipfw2 supports diverting of IPv6 packets. Yay!
  • A simple program which listens on the divert socket (IPPROTO_DIVERT) for IPv4 (PF_INET) and prints some information about the packets received works. Yay!
  • That same program for IPv6 (PF_INET6) doesn't work, lsof says that it is listening for protocol 0 (the catch all) instead of protocol IPPROTO_DIVERT.
  • Looking through ip_divert() in src/netinet/ip_divert.c shows about the registration of protocols (thanks to bms@ for hints): pf_proto_register(PF_INET, &div_protosw), but when I do this for PF_INET6 it returns an error which is related to the absence of a free IPPROTO_SPACER. And these are (thanks to rwatson@ for hints) not available for IPv6.

So, this is getting trickier and trickier for an userland guy like me to experiment with on a sunday afternoon... But I'm not going to give up! (yet)

On the other hand, an interesting paper by Dr. Goto (I'm not kidding) and friends available at IPV4/V6 NETWORK EMULATOR USING DIVERT SOCKET says: 

[...]
We have ported divert socket to IPv6 by adding about 1000
lines of C program code either on FreeBSD and Linux kernel
for this research.
[...]
I have asked him if he wanted to share his code but haven't heard anything back from him.

Posted on May 06, 2008 10:00 AM

  Ryan French (rfrench)  

Hello World!!

Time for the obligatory Hello World post. This blog will be a resource mostly on developing a networking protocol for FreeBSD, due to the nature of the Summer of Code project I am working on (MPLS in FreeBSD). This blog will be fed off my main blog, www.driven-monkey.com, but if you want to leave a comment here I’ll get back to you asap.

Posted on May 06, 2008 04:22 AM

 

May 05, 2008

  Matteo Riondato (matteo)  [stats, website]

Laptop Status

I’m pretty happy of the status of the FreeBSD installation on my laptop: I’m running HEAD and have skype-devel, jdk15, eclipse, and OpenOffice.org-2.4. Eventually, last night I moved my home to a new slice with GELI+Gjournal.

Still to do: Tor configuration…and flash: gnash doesn’t seem to be so stable ATM on my laptop..It may be X.org’s, drm’s, or gnash’s fault, or who knows…

Posted on May 05, 2008 05:55 PM

  Konrad Jankowski (konrad)  

Hello world!

Welcome to FreeBSD Committers Blogs. This is your first post. Edit or delete it, then start blogging!

Posted on May 05, 2008 01:51 PM

 

May 04, 2008

  Rui Paulo (rpaulo)  

First entry

Hello there,
This my first entry. I decided to finally start blogging about FreeBSD. :-)
I’m also participating in this years SoC with the TCP anomaly detector project, so, this blog will mainly talk about that.

Good luck to everyone on this years SoC!

Posted on May 04, 2008 03:16 PM

  Philip Paeps (philip)  [stats, website]

Playing with zsh

Ever since ... well, forever, people have been telling me to try zsh. I have been a happy tcsh user since the beginning of time, and have never seen a reason to switch.

According to the documentation, zsh is a hybrid shell that combines all the useful features of tcsh and ksh, has somehow managed to find good features in bash to include as well (I wonder how that works, I've never managed to find any good features in bash, only annoyances) and adds some interesting new stuff on top.

The implied bloat of this alone has kept me away from zsh for a while. In fact, the binary is about the same size as bash. Which isn't bad, considering that bash takes all this space without offering any functionality and zsh offers heaps.

Being bored over the long weekend, I took a closer look at zsh and tried to teach it about the things I have grown to like in tcsh. This turned out to be surprisingly easy. In fact, the only mildly tricky bit was teaching zsh about the addictive run-fg-editor command, which I bind to ^Z and which is very addictive.

Six lines in my .zshrc do the trick, however:

# Emulate tcsh's run-fg-editor
run-fg-editor() {
    zle push-input
    BUFFER="fg %$EDITOR:t"
    zle accept-line
}
zle -N run-fg-editor

Another annoyance is the way the backward-delete-word function likes to eat whole paths. As far as I know, only tcsh gets this right by default. That is, if I've got something like cd /usr/local/tools/xchains/arm/arm9 in my buffer and press ^W, I only want the arm9 to go away, not the whole path. You'd think that would count as sensible default. Like the run-fg-editor bit, this was also fairly easy to fix:

# Emulate tcsh's backward-delete-word
tcsh-backward-delete-word () {
    local WORDCHARS="${WORDCHARS:s#/#}"
    zle backward-delete-word
}
zle -N tcsh-backward-delete-word

After I got zsh behaving like tcsh, I checked to make sure that some of the constructions I use all the time still worked:

[204] (philip@carrot)~/tmp% touch foo
[205] (philip@carrot)~/tmp% cp foo !#:1.orig
cp foo foo.orig
[206] (philip@carrot)~/tmp%

[206] (philip@carrot)~/tmp% !204:s/foo/bar/
touch bar
[207] (philip@carrot)~/tmp% !205:gs/foo/bar/
cp bar bar.orig
[208] (philip@carrot)~/tmp%

[208] (philip@carrot)~/tmp% !to
touch bar
[209] (philip@carrot)~/tmp% !cp
cp bar bar.orig
[210] (philip@carrot)~/tmp%

Yes - I'm a great fan of history substitution. And of the foreach loop and modifiers:

[210] (philip@carrot)~/tmp% mkdir foreach
[211] (philip@carrot)~/tmp% cd !$
cd foreach
[212] (philip@carrot)~/tmp/foreach% touch alpha beta gamma
[213] (philip@carrot)~/tmp/foreach% foreach file (*)
foreach> mv $file $file:u
foreach> end
[214] (philip@carrot)~/tmp/foreach% ll
total 0
-rw-rw-r--  1 philip  philip  0 May  4 13:49 ALPHA
-rw-rw-r--  1 philip  philip  0 May  4 13:49 BETA
-rw-rw-r--  1 philip  philip  0 May  4 13:49 GAMMA
[215] (philip@carrot)~/tmp/foreach%

I also make the occasional typo:

[215] (philip@carrot)~/tmp/foreach% iv GAMMA
zsh: correct 'iv' to 'vi' [nyae]?

Excellent. :-)

I'll be playing with this some more... I'm particularly interested in learning about the "fully programmable completion". If I read the documentation right, it's like tcsh completion on acid. Sounds like fun.

My only worry is that zsh is the "shell of choice" in the build system at work. So who knows what kind of horrible voodoo rites I'll need to perform to have both a sensible interactive environment (which the default isn't) and be able to create bootable builds (which a sensible interactive environment surely can't).

It seems zsh offers the possibility to be started with a different set of dotfiles. I think together with modules (thanks again for that tip, Jan, I think I already told you I'm addicted), I should be able to hack something together.

Fun fun fun!

Posted on May 04, 2008 12:02 PM

 

May 02, 2008

  Gábor Kövesdán (gabor)  

SoC 2008: Porting BSD-licensed Text-Processing Tools from OpenBSD

This year, I’m working on porting grep, sort and diff from OpenBSD. You can read more about my project in the original proposal. If you wanto to see the progress, you can look at my wiki page, although I’m going to post the most important milestones here.

Posted on May 02, 2008 04:18 PM

  Diego Giagio (diego)  

First post

This is my first post. If you would like to know more about me and this blog, please go to the about page.

Posted on May 02, 2008 11:42 AM

 

May 01, 2008

  Vincenzo Iozzo (snagg)  

First post, me and my project

Hi all,I’m Vincenzo Iozzo, currently I’m studying computer engineering at the Politecnico di Milano. I also work for Secure Network srl. And in the spare time I do some research for my university. I’m mainly involved in IT Security.   Now, after this brief presentation, I’d like to spend a few words on my project for this Summer Of Code.  I will modify the FreeBSD auditpipe support in order to provide more granularity while auditing syscalls. In fact, at the present time, your choice on what to audit is limited to default classes. With my patch it would be possible to select every syscall by its own. The second half of the project will consist of creating a framework for testing the correct behavior of the auditing system and, if needed, patching it.Finally the whole auditing system will be checked in order to see whether or not is vulnerable at some anti-forensics techiniques.  Here you can find a detailed description of the first part of the project.Snagg

Posted on May 01, 2008 04:59 PM

  Edwin Groothuis (edwin)  [stats, website]

Three Mobile roaming 3G network

Thanks to my job, or cursed by my job sometimes, I have access to a 3G modem of Three Mobile. It works fine in areas where there is Three Mobile coverage, outside these areas were we are roaming (and probably on the Telstra 3G network) there are interesting issues with the IPCP phase (IP Confirguration Protocol) of PPP which make the PPP setup fail.

So what works and what doesn't? According to the PPP manual, this is what we should see: 

ppp ON awfulhak> # No link has been established
Ppp ON awfulhak> # We've connected & finished LCP
PPp ON awfulhak> # We've authenticated
PPP ON awfulhak> # We've agreed IP numbers
The first two Ps become capitals, but the third one doesn't when we are roaming.

What do the logs say? The short version of a successful handshake is: 

IPCP: FSM: Using "deflink" as a transport
IPCP: deflink: State change Initial --> Closed
IPCP: deflink: LayerStart.
IPCP: deflink: SendConfigReq(1) state = Closed
IPCP: deflink: State change Closed --> Req-Sent
IPCP: deflink: RecvConfigNak(1) state = Req-Sent
IPCP: deflink: SendConfigReq(2) state = Req-Sent
IPCP: deflink: RecvConfigNak(2) state = Req-Sent
IPCP: deflink: SendConfigReq(3) state = Req-Sent
IPCP: deflink: RecvConfigReq(0) state = Req-Sent
IPCP: deflink: SendConfigNak(0) state = Req-Sent
IPCP: deflink: RecvConfigRej(3) state = Req-Sent
IPCP: deflink: SendConfigReq(4) state = Req-Sent
IPCP: deflink: RecvConfigReq(1) state = Req-Sent
IPCP: deflink: SendConfigAck(1) state = Req-Sent
IPCP: deflink: State change Req-Sent --> Ack-Sent
IPCP: deflink: RecvConfigNak(4) state = Ack-Sent
IPCP: deflink: SendConfigReq(5) state = Ack-Sent
IPCP: deflink: RecvConfigAck(5) state = Ack-Sent
IPCP: deflink: State change Ack-Sent --> Opened
The full log is at the end of this writeup.
The discussion goes like this: I propose something three times (SendConfigReq) and they reject it (RecvConfigNak), but at the third time they say "Let's try it with this" (RecvConfigReq) and we come up with a common ground. And everybody is happy!

The short version of an unsuccessful handshake is: 

IPCP: FSM: Using "deflink" as a transport
IPCP: deflink: State change Initial --> Closed
IPCP: deflink: LayerStart.
IPCP: deflink: SendConfigReq(1) state = Closed
IPCP: deflink: State change Closed --> Req-Sent
IPCP: deflink: RecvConfigNak(1) state = Req-Sent
IPCP: deflink: SendConfigReq(2) state = Req-Sent
IPCP: deflink: RecvConfigNak(2) state = Req-Sent
IPCP: deflink: SendConfigReq(3) state = Req-Sent
IPCP: deflink: RecvConfigNak(3) state = Req-Sent
IPCP: deflink: SendConfigReq(4) state = Req-Sent
IPCP: deflink: RecvConfigNak(4) state = Req-Sent
IPCP: deflink: SendConfigReq(5) state = Req-Sent
IPCP: deflink: RecvConfigNak(5) state = Req-Sent
IPCP: deflink: SendConfigReq(6) state = Req-Sent
IPCP: deflink: RecvConfigNak(6) state = Req-Sent
IPCP: deflink: SendConfigReq(7) state = Req-Sent
IPCP: deflink: RecvConfigNak(7) state = Req-Sent
IPCP: deflink: SendConfigReq(8) state = Req-Sent
IPCP: deflink: RecvConfigNak(8) state = Req-Sent
IPCP: deflink: SendConfigReq(9) state = Req-Sent
IPCP: deflink: RecvConfigNak(9) state = Req-Sent
IPCP: deflink: SendConfigReq(10) state = Req-Sent
IPCP: deflink: RecvConfigNak(10) state = Req-Sent
IPCP: deflink: SendConfigReq(11) state = Req-Sent
IPCP: deflink: SendTerminateReq(11) state = Req-Sent
IPCP: deflink: State change Req-Sent --> Closing
IPCP: deflink: RecvTerminateAck(11) state = Closing
IPCP: deflink: LayerFinish.
IPCP: deflink: State change Closing --> Closed
IPCP: deflink: RecvConfigNak(11), dropped (expected 12)
The full log is at the end of this writeup.
Here there are only SendConfigReq and RecvConfigNak, there is no RecvConfigReq coming from them!

If anybody has managed to setup a successful PPP connection on the 3G network of anybody but Three Mobile can send me some logs, I would be very happy to see if I can fix things.

Here are the full logs:

This is the IPCP part of a successful handshake 

ppp[1098]: tun0: Phase: bundle: Network
ppp[1098]: tun0: IPCP: FSM: Using "deflink" as a transport
ppp[1098]: tun0: IPCP: deflink: State change Initial --> Closed
ppp[1098]: tun0: IPCP: deflink: LayerStart.
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed
ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression
ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.76.66
ppp[1098]: tun0: IPCP: SECDNS[6] 255.255.255.255
ppp[1098]: tun0: IPCP: deflink: State change Closed --> Req-Sent
ppp[1098]: tun0: LCP: deflink: RecvProtocolRej(2) state = Opened
ppp[1098]: tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected!
ppp[1098]: tun0: CCP: deflink: State change Req-Sent --> Stopped
ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(1) state = Req-Sent
ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1098]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1098]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1098]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(2) state = Req-Sent
ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression
ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(2) state = Req-Sent
ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1098]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1098]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1098]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(3) state = Req-Sent
ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression
ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: RecvConfigReq(0) state = Req-Sent
ppp[1098]: tun0: IPCP: [EMPTY]
ppp[1098]: tun0: IPCP: deflink: SendConfigNak(0) state = Req-Sent
ppp[1098]: tun0: IPCP: IPADDR[6] 10.0.0.2
ppp[1098]: tun0: IPCP: deflink: RecvConfigRej(3) state = Req-Sent
ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(4) state = Req-Sent
ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: RecvConfigReq(1) state = Req-Sent
ppp[1098]: tun0: IPCP: [EMPTY]
ppp[1098]: tun0: IPCP: deflink: SendConfigAck(1) state = Req-Sent
ppp[1098]: tun0: IPCP: [EMPTY]
ppp[1098]: tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent
ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(4) state = Ack-Sent
ppp[1098]: tun0: IPCP: IPADDR[6] 119.11.8.120
ppp[1098]: tun0: IPCP: IPADDR[6] changing address: 0.0.0.0 --> 119.11.8.120
ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.68.130
ppp[1098]: tun0: IPCP: SECDNS[6] 202.124.76.66
ppp[1098]: tun0: IPCP: Primary nameserver set to 202.124.68.130
ppp[1098]: tun0: IPCP: Secondary nameserver set to 202.124.76.66
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(5) state = Ack-Sent
ppp[1098]: tun0: IPCP: IPADDR[6] 119.11.8.120
ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.68.130
ppp[1098]: tun0: IPCP: SECDNS[6] 202.124.76.66
ppp[1098]: tun0: IPCP: deflink: RecvConfigAck(5) state = Ack-Sent
ppp[1098]: tun0: IPCP: IPADDR[6] 119.11.8.120
ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.68.130
ppp[1098]: tun0: IPCP: SECDNS[6] 202.124.76.66
ppp[1098]: tun0: IPCP: deflink: State change Ack-Sent --> Opened
ppp[1098]: tun0: IPCP: deflink: LayerUp.

This is the IPCP part of a unsuccessful handshake 

ppp[1661]: tun0: Phase: bundle: Network
ppp[1661]: tun0: IPCP: FSM: Using "deflink" as a transport
ppp[1661]: tun0: IPCP: deflink: State change Initial --> Closed
ppp[1661]: tun0: IPCP: deflink: LayerStart.
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: State change Closed --> Req-Sent
ppp[1661]: tun0: LCP: deflink: RecvProtocolRej(2) state = Opened
ppp[1661]: tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected!
ppp[1661]: tun0: CCP: deflink: State change Req-Sent --> Stopped
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(1) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(2) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(2) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(3) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(3) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(4) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(4) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(5) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(5) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(6) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(6) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(7) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(7) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(8) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(8) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(9) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(9) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(10) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(10) state = Req-Sent
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(11) state = Req-Sent
ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14
ppp[1661]: tun0: Command: /dev/ttyp1: quit
ppp[1661]: tun0: IPCP: deflink: SendTerminateReq(11) state = Req-Sent
ppp[1661]: tun0: IPCP: deflink: State change Req-Sent --> Closing
ppp[1661]: tun0: IPCP: deflink: RecvTerminateAck(11) state = Closing
ppp[1661]: tun0: IPCP: deflink: LayerFinish.
ppp[1661]: tun0: IPCP: Connect time: 11 secs: 0 octets in, 0 octets out
ppp[1661]: tun0: IPCP: 0 packets in, 0 packets out
ppp[1661]: tun0: IPCP: total 0 bytes/sec, peak 0 bytes/sec on Thu Apr 24 13:39:49 2008
ppp[1661]: tun0: IPCP: deflink: State change Closing --> Closed
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(11), dropped (expected 12)
ppp[1661]: tun0: Phase: bundle: Terminate

Posted on May 01, 2008 08:00 AM

FreeBSD Logo

Disclaimer

"FreeBSD" and the FreeBSD logo are Trademarks of the FreeBSD Foundation.
Blog entries aggregated on this page are owned by, and represent the opinion of the author.

Planet FreeBSD

Planet FreeBSD is hosted and maintained by Florent Thoumie.
If you feel like your blog {sh,c}ould be aggregated here, drop me an email.

Last update:
May 12, 2008 01:00 AM UTC

Subscriptions

Planet Flavours

Links

Powered by

Planet FreeBSD Python Apache

Syndicate this Planet!