Re: establish connection without tcp options
On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann <[EMAIL PROTECTED]> wrote: > Victor Hugo Bilouro wrote: >> >> On Sun, Jun 1, 2008 at 8:00 AM, Andre Oppermann <[EMAIL PROTECTED]> wrote: >>> >>> Victor Hugo Bilouro wrote: On Thu, May 29, 2008 at 5:01 AM, Andre Oppermann <[EMAIL PROTECTED]> wrote: > > Victor Hugo Bilouro wrote: >> >> Hi all, >> >> I'm working into establish manually a tcp connection. >> >> Does anyone knows if freebsd 7.0 stable agree, a connection >> establishment without TCP options set? > > Yes, certainly it does. If you send a SYN w/o any options it > won't use any. If you establish a connection from FreeBSD you > may ignore any options in SYN and in your SYN-ACK not send any. > If you want FreeBSD not to send any options you can set the > socket option TCP_NOOPT before you do the connect. > > -- > Andre > Hello, First thanks Andre! So, as I told before, I'm trying to connect manually, but, something wrong is occurring, after accomplish 3way-handshake, the server (passive open) is sending a RESET. You can see by tcpdump dump, that everything is OK. tcpdump -ied0 -S -vv tcp 08:58:21.302052 IP (tos 0x0, ttl 64, id 55136, offset 0, flags [none], proto TCP (6), length 40) 192.168.1.10.53639 > 192.168.1.20.22022: S, cksum 0x2a4d (correct), 3204258715:3204258715(0) win 65535 08:58:21.302125 IP (tos 0x0, ttl 64, id 411, offset 0, flags [DF], proto TCP (6), length 44) 192.168.1.20.22022 > 192.168.1.10.53639: S, cksum 0xba99 (correct), 400703492:400703492(0) ack 3204258716 win 65535 08:58:21.697561 IP (tos 0x0, ttl 64, id 55137, offset 0, flags [none], proto TCP (6), length 40) 192.168.1.10.53639 > 192.168.1.20.22022: ., cksum 0xacf0 (correct), 0:0(0) ack 400703493 win 65535 08:58:21.697632 IP (tos 0x0, ttl 64, id 412, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.20.22022 > 192.168.1.10.53639: R, cksum 0xacfc (correct), 400703493:400703493(0) win 0 Any suggestions? >>> >>> Enable net.inet.tcp.log_debug=1 and watch the log output. It will >>> tell you where it stumbled. >>> >>> -- >>> Andre >>> BTW, I'm GSoC student, doing TCP/IP Regression Test Suite. This code at bilouro_tcptest client at perfoce. (//depot/projects/soc2008/bilouro_tcptest/) This script: //depot/projects/soc2008/bilouro_tcptest/src/scripts/tcpconnect.py Best >>> >> >> cool I didn't know this... >> >> I'm seeing /var/log/debug.log and actually something is wrong >> >> syn- >> sport 56054 >> dport 22022 >> sequence 2992965889 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 16400 >> urg_pointer 0 >> - >> >> syn+ack- >> sport 22022 >> dport 56054 >> sequence 2079194755 >> ack_number 2992965890 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 65535 >> checksum 44497 >> urg_pointer 0 >> - >> >> ack- >> sport 56054 >> dport 22022 >> sequence 0 > > ^ should be 2992965890 > >> ack_number 2079194756 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 33014 >> urg_pointer 0 >> - >> >> /var/log/debug.log: >> TCP [192.168.1.10]:56054 to [192.168.1.20]:22022 tcpflags 0x10; >> syncache_expand: SEQ 0 != IRS+1 2992965889, segment rejected. > > The sequence number of your segment is neither the previous value > not is incremented by one to account for the SYN. > >> Even though I know in step #3 of 3way-handshake I don't need pass the >> sequence, I sent a sequence... > > You do have to pass the sequence number at any time. And it has > to be correct all the time. > >> syn- >> sport 59966 >> dport 22022 >> sequence 874312230 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 50667 >> urg_pointer 0 >> >> - >> >> syn+ack- >> sport 22022 >> dport 59966 >> sequence 2755934977 >> ack_number 874312231 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 65535 >> checksum 52952 >> urg_pointer 0 >> >> - >> >> ack- >> sport 59966 >> dport 22022 >> sequence 874312230 > > ^^ increment by one for SYN you sent. > See also the ACK you got back above. > >> ack_number 2755934978 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 59030 >> u
Re: HEAD UP: non-MPSAFE network drivers to be disabled
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes : >In the past I've uesd line disciplines to implement a keyboard driver >for the Apple Newton Keyboard (serial protocol) [...] But shouldn't you have used uart(4) for that ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled
In message: <[EMAIL PROTECTED]> "Bruce M. Simpson" <[EMAIL PROTECTED]> writes: : Other than that, line disciplines can go away. In the past I've uesd line disciplines to implement a keyboard driver for the Apple Newton Keyboard (serial protocol) so I could use it at any point after the loader (the system didn't run X11, so I couldn't use the X11 driver I wrote there). This system has been retired, and I don't think I ever forward ported them past about 3.mumble, if even that far. This code is badly decayed, and I have no requirement that it continues to work. But I know similar techniques are used in some embedded systems. Expect some delayed complaining if they go away entirely. But that may be OK given we're ridding tty of Giant. Now, if we could only sort out the syscons/keyboard/mouse mess... Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled
In message: <[EMAIL PROTECTED]> Robert Watson <[EMAIL PROTECTED]> writes: : : On Mon, 26 May 2008, Bruce M. Simpson wrote: : : >> Given that this is (a) 2008 and (b) 8.x we're talking about, are there : >> really that many consumers of SLIP to warrant it being carried forward at : >> all? : > : > It's kind of a basic. [C]SLIP has been historically handy to have around for : > situations which warrant it. Mind you, given that we have had tun(4) in the : > tree for years now, a userland implementation of SLIP is possible. : > : > As with all of these things it's down to someone sitting down and doing it. : > : > I'm not volunteering to support any of this as I don't use it myself (got : > enough on my plate), merely pointing out that support for SLIP in a system : > is something many people have taken for granted over the years, and for : > prototyping something or providing IP over a simple serial link without the : > configuration overhead of PPP, SLIP is something someone might be using. : > : > P.S. ahc(4) is commodity hardware, I think it can stay right where it is : > thank-you. : : My suspicion is that getting SLIP basically working in userspace is fairly : straight forward, SLiRP and friends have been doing this for years. I made my living for about a year working on TIA, which was a portable, userland implementation of PPP and SLIP/CSLIP. This was in about 1995 or so. It isn't that hard... : SLIP has its subtleties, but the current implementation is relatively : straight-forward, well-documented, etc. Yes, especially CSLIP. But frankly, they are a whole lot easier than PPP to get up and going... Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0
On Sat, May 31, 2008 at 01:40:47PM +0200, Fuchs, Martin wrote: > Ok, back again... sorry for letting you wait so long, but i had a lot to > do... > > Since there's no possibility to copy via putty i'm copying by hand... > hopefully there are not too many errors :-) > > - > pciconf -lcv > > ... > [EMAIL PROTECTED]:1:4:0: class=0x02 card=0x00708086 > chip=0x12298086 rev=x010 > hdr=0x00 > class = network > subclass= ethernet > cap01[dc] = powerspec 2 supportsD0 D1 > D2 D3 current D0 > > [EMAIL PROTECTED]:1:5:0: class=0x02 card=0x00708086 > chip=0x12298086 rev=x010 > hdr=0x00 > class = network > subclass= ethernet > cap01[dc] = powerspec 2 supportsD0 D1 > D2 D3 current D0 > > [EMAIL PROTECTED]:1:8:0: class=0x02 card=0x30118086 > chip=0x103a8086 rev=x010 > hdr=0x00 > class = network > subclass= ethernet > cap01[dc] = powerspec 2 supportsD0 D1 > D2 D3 current D0 > It looks like fxp0/fxp1 is 82551 Pro and fxp2 is 82801 DB(ICH4). > - > dmesg shows for example: > > fxp0: link state changed to down > fxp1: link state changed to down > fxp2: link state changed to down > fxp1: link state changed to up <- when I attach a network cable to a > switch That's normal. All ethernet drivers should detect link up event. > > - > devinfo does not work... does not find the command (it's the freebsd under > pfSense) > Hmm, I don't know layout of pfSense but I guess it's not good idea to remove such a small/good program. > - > vmstat -i > > interrupttotal rate > irq0: clk1348688 999 > irq5: ehci0 90436 > irq8: rtc172621 127 > irq10: fxp1 91 0 > irq12: fxp0 86 0 > irq14: uhci0 ata0792 0 > irq15: ata1 27382 > Total1534059 1137 > > - > > Hope you can use this information ? > This looks odd, where is fxp2? Therere is no '+' mark in vmstat output so I think there should be at least an entry for fxp2. Because you have two differnet kinds of NICs would you let me know which one is not working? Also full dmesg output would be helpful, I guess. -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
