Re: how to stop the "automatic reboot"
I'm not certain, but maybe pressing the pause-break key on your keyboard will work. This has saved me in the past. On 1/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Pressing a key after the "Automatic reboot in 15 seconds - press a key on the console to abort" message does not seem to prevent the reboot. What is the correct way of stopping it long enough to copy the other messages? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vpnc problem
I am trying to use vpnc 0.3.3 on FreeBSD 6.1 but I get the following errors route: bad address: delete net default Also this completely screws up the network on my machine :( Has anyone being successfully in using vpnc 0.3.3 on FreeBSD 6.1? Thanks. - Vishal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Interesting TCP issue
One of my users is having trouble receiving mail from Skype. So, after some sniffing, I discovered this: # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 bytes 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp: P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 0x: 4520 004a 3260 4000 3a06 c609 d5f4 aa50 [EMAIL PROTECTED]:..P 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..Jk.. 0x0020: 8018 002e 9297 0101 080a 95b8 5568 ..Uh 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 0x: 4520 004a 3261 4000 3a06 c608 d5f4 aa50 [EMAIL PROTECTED]:..P 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..Jk.. 0x0020: 8018 002e 1d67 0101 080a 95b8 ca98 .g.. 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. And no responses from my system. Interesting. I presume it has something to do with the idiotically small window the remote server is advertising. So I set net.inet.tcp.minmss down to 46, and that resulted in a RST being spit back to skype's server when its retransmit happened. 13:20:13.610975 IP (tos 0x20, ttl 58, id 12897, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp: P, cksum 0x1d67 (correct), 0:22(22) ack 1 win 46 13:20:13.611036 IP (tos 0x20, ttl 64, id 39789, offset 0, flags [DF], proto: TCP (6), length: 40) wattres.watt.com.smtp > share.skype.net.50406: R, cksum 0x5b51 (correct), 1248591103:1248591103(0) win 0 0x: 4520 0028 9b6d 4000 4006 571e 425d 8582 E..([EMAIL PROTECTED]@.W.B].. 0x0010: d5f4 aa50 0019 c4e6 4a6b fcff ...PJk.. 0x0020: 5004 5b51 P...[Q.. The packets shown here are the complete capture. I can hand-type stuff to the skype server and it appears to get through just fine, but when it connects to my box, no segments make their way back to skype. I can see them sitting in the Send-Q: # netstat -f inet Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address(state) [ ... ] tcp4 0213 wattres.smtp share.skype.net.50406 ESTABLISHED [ ... ] Very strange. Any opinions on possible workarounds, since I'm not expecting Skype to fix their (broken) system? -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Interesting TCP issue
> From Steve Watt on Monday, January 01, 2007 4:37 PM > > # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 > tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 > bytes > 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], > proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp: > P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 > > 0x: 4520 004a 3260 4000 3a06 c609 d5f4 aa50 [EMAIL > PROTECTED]:..P > 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..Jk.. > 0x0020: 8018 002e 9297 0101 080a 95b8 5568 ..Uh > 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.s > 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. > > Interesting. I presume it has something to do with the > idiotically small window the remote server is advertising. So I > set net.inet.tcp.minmss down to 46, and that resulted in a RST > being spit back to skype's server when its retransmit happened. Are you sure the window is really that small and that window scaling was not negotiated at the start of the connection? The initial packets are not captured here so I can't tell. Is it possible to get a really complete capture of a session including the initial handshake? David ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Confusion in acpi_sleep_machdep().
In message <[EMAIL PROTECTED]>, Matthew Dillon w rites: >I'm trying to figure out how the acpi_sleep_machdep() code works and >there are a couple of lines I just don't understand: > >pm = vmspace_pmap(p->p_vmspace); >cr3 = rcr3(); >#ifdef PAE >load_cr3(vtophys(pm->pm_pdpt)); >#else >load_cr3(vtophys(pm->pm_pdir)); >#endif > >page = PHYS_TO_VM_PAGE(sc->acpi_wakephys); >pmap_enter(pm, sc->acpi_wakephys, page, > VM_PROT_READ | VM_PROT_WRITE | VM_PROT_EXECUTE, 1); > >First, why isn't it just using kernel_pmap ? What's all the load_cr3() >stuff for ? > >Second, why is it entering the physical address sc->acpi_wakephys >as the virtual address in the pmap ? Shouldn't it be using >sc->acpi_wakeaddr there? > >Anybody know ? I don't know the details, but acpi_sleep_machdep() sets up an identity mapping in the current process's vmspace (hence using virtual = physical). Lazy switching of address spaces means that cr3 may not currently refer to the same vmspace, which would break the identity mapping, so that's the reason for the load_cr3() calls. See revision 1.22 for a bit more information. Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
getgroups and getgrouplist functions
Just working on fixing the problem with DBus for when a user is a member of more than 16 groups. I have NGROUPS_MAX set to 64 on this system. So far I have one person on the DBus mailing list telling me that the FreeBSD getgrouplist is broken. I just want to verify if how I am reading the docs is correctly. I am reading it as int *ngroups is not set to the number of groups in the list if the number of groups is larger than the number specified. They are saying it does not make a difference because getgroupslist will do it regardless. Based on testing and reading the man, I am convinced this is a load of bull. And the proper way to get the number of groups some one is in is to call getgroups(0). Any one have any opinions or would like to hear more? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interesting TCP issue
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: >> From Steve Watt on Monday, January 01, 2007 4:37 PM >> >> # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 [ snip ] >> Interesting. I presume it has something to do with the >> idiotically small window the remote server is advertising. So I >> set net.inet.tcp.minmss down to 46, and that resulted in a RST >> being spit back to skype's server when its retransmit happened. > >Are you sure the window is really that small and that window scaling was not >negotiated at the start of the connection? The initial packets are not captured >here so I can't tell. > >Is it possible to get a really complete capture of a session including the >initial >handshake? Good point. Here's the full capture from a different session. Same tcpdump flags. My FreeBSD box (a.k.a. wattres.watt.com) said wscale 1, so that's (if I remember my TCP correctly) what gets used. Note after the ACK from share.skype.net, my machine doesn't ACK the segment with the EHLO in it, so we get retransmits. At the application level, I can see that sendmail got the EHLO, because the milter cb_helo callback happened. I wasn't at the box when this particular connection attempt happened, so I couldn't see the Send Q in netstat, but this is exactly the same appearance as the snippet I showed earlier, so I'm presuming a similar failure occurred. Very strange behavior. 22:44:17.578821 IP (tos 0x20, ttl 58, id 56305, offset 0, flags [DF], proto: TCP (6), length: 60) share.skype.net.59816 > wattres.watt.com.smtp: S, cksum 0xf0c3 (correct), 1414414327:1414414327(0) win 5840 0x: 4520 003c dbf1 4000 3a06 1c86 d5f4 aa50 E..<[EMAIL PROTECTED]:..P 0x0010: 425d 8582 e9a8 0019 544e 3ff7 B]..TN?. 0x0020: a002 16d0 f0c3 0204 05b4 0402 080a 0x0030: 9639 e406 0103 0307.9.. 22:44:17.578958 IP (tos 0x0, ttl 64, id 30930, offset 0, flags [DF], proto: TCP (6), length: 64) wattres.watt.com.smtp > share.skype.net.59816: S, cksum 0xb1c9 (correct), 1236670735:1236670735(0) ack 1414414328 win 65535 0x: 4500 0040 78d2 4000 4006 79c1 425d 8582 [EMAIL PROTECTED]@[EMAIL PROTECTED] 0x0010: d5f4 aa50 0019 e9a8 49b6 190f 544e 3ff8 ...PI...TN?. 0x0020: b012 b1c9 0204 05b4 0103 0301 0x0030: 0101 080a 2107 c0ed 9639 e406 0402 !9.. 22:44:17.742243 IP (tos 0x20, ttl 58, id 56306, offset 0, flags [DF], proto: TCP (6), length: 52) share.skype.net.59816 > wattres.watt.com.smtp: ., cksum 0xf13d (correct), 1:1(0) ack 1 win 46 0x: 4520 0034 dbf2 4000 3a06 1c8d d5f4 aa50 [EMAIL PROTECTED]:..P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1910 B]..TN?.I... 0x0020: 8010 002e f13d 0101 080a 9639 e42f .=...9./ 0x0030: 2107 c0ed!... 22:44:17.785110 IP (tos 0x0, ttl 64, id 30938, offset 0, flags [DF], proto: TCP (6), length: 64) wattres.watt.com.57166 > share.skype.net.auth: S, cksum 0x6899 (correct), 2124104998:2124104998(0) win 65535 0x: 4500 0040 78da 4000 4006 79b9 425d 8582 [EMAIL PROTECTED]@[EMAIL PROTECTED] 0x0010: d5f4 aa50 df4e 0071 7e9b 4526 ...P.N.q~.E& 0x0020: b002 6899 0204 05b4 0103 0301 h... 0x0030: 0101 080a 2107 c1ba 0402 !... 22:44:17.947113 IP (tos 0x20, ttl 58, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) share.skype.net.auth > wattres.watt.com.57166: R, cksum 0xc429 (correct), 0:0(0) ack 2124104999 win 0 0x: 4520 0028 4000 3a06 f88b d5f4 aa50 E..([EMAIL PROTECTED]:..P 0x0010: 425d 8582 0071 df4e 7e9b 4527 B]...q.N~.E' 0x0020: 5014 c429 P) 22:44:17.952929 IP (tos 0x0, ttl 64, id 30939, offset 0, flags [DF], proto: TCP (6), length: 98) wattres.watt.com.smtp > share.skype.net.59816: ., cksum 0x3baf (correct), 1:47(46) ack 1 win 33304 0x: 4500 0062 78db 4000 4006 7996 425d 8582 [EMAIL PROTECTED]@.y.B].. 0x0010: d5f4 aa50 0019 e9a8 49b6 1910 544e 3ff8 ...PI...TN?. 0x0020: 8010 8218 3baf 0101 080a 2107 c262 ;...!..b 0x0030: 9639 e42f 3232 3020 7761 7474 7265 732e .9./220.wattres. 0x0040: 7761 7474 2e63 6f6d 2045 534d 5450 2053 watt.com.ESMTP.S 0x0050: 656e 646d 6169 6c20 382e 3133 2e38 2f38 endmail.8.13.8/8 0x0060: 2e31 .1 22:44:18.115814 IP (tos 0x20, ttl 58, id 56307, offset 0, flags [DF], proto: TCP (6), length: 52) share.skype.net.59816 > wattres.watt.com.smtp: ., cksum 0xef3d (correct), 1:1(0) ack 47 win 46 0x: 4520 0034 dbf3 4000 3a06 1c8c d5f4 aa50 [EMAIL PROTECTED]:..P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 193e B]...
