Re: MACs vs Hash fns. and collision resistance
You could just as easily use a CRC function, which has the nice property of having a collision rate of 2^l, where l is the length of the CRC. CRCs are also pretty low-cost to compute relative to other methods. -scooter At 09:47 PM 8/25/00 -0400, you wrote: >[I see my post made it] > >To expand briefly on my comment about collision resistance > > > - the hash function constructed from using Blowfish in CBC mode you -- > > have to be careful how you use block ciphers to construct hash > > functions -- they have quite different properties. For example > > collision resistance is not generally important for a block cipher, > > but is all-important for a hash function To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Odd TCP glitches in new currents
We aren't doing mcast at this time. If there's anyone from Nortel lurking behind this list, UCLA CS is pretty close to throwing out the Accelars due to a lack of tech support response. No, UCLA CS is not capable of doing department-wide mcast because of a set of peculiar bugs in the Accelar's code. It will only do DVMRP snooping on a limited number of mcast groups (~400 or so). What we actually see is 3x that number. And so we're waiting for some upgraded code that Nortel/Bay has claimed is coming for the better part of a year now. -scooter On Fri, 24 Dec 1999, Glendon Gross wrote: > > Are you sure that this is a problem with the local interface dropping > packets, or could it just be a multicast router > that is suppressing packets? I have noticed with my new FreeBSD box > running mrouted, exceptionally good routing performance. But my linux > boxes are more consistent in their response. So I concluded that > my upstream neighbors are supressing the broadcasts as a feature of the > multicast routing protocol. I don't think it's a problem with my local > interface, just a feature of the DVMRP protocol. > > Can anyone recommend a good reference on this? I've been reading RFC-1075 > and don't really understand it.--Glen Gross > > On Tue, 30 Nov 1999, B. Scott Michel wrote: > > > On Wed, 22 Dec 1999, Jonathan Lemon wrote: > > > > > On Dec 12, 1999 at 11:37:42AM -0800, Matthew Dillon wrote: > > > I had a Netgear FS509 switch here that would eat packets transmitted > > > through the GigE port under certain conditions. Netgear shipped me > > > a new one, and I've been happy with it, until the same problem started > > > happening again this morning. > > > > There's some oddities in the 3.3 and 3.4 kernels as well -- I've actually > > nailed down the plexicity and speed on both the Accellar and my humble PC, > > and yet, I'm looking at weird TCP lockups from time to time. > > > > Mostly seems to be related to NFSv3, but will also happen when doing > > cvsup. There's no magic number of how many bytes are queued waiting to go > > out the interface. And it seems to be limited to specific connections, > > i.e. an NFS TCP connection can be jammed and yet I can be happily talking > > to cvsup3 doing an update. > > > > The interface in question is a NetGear: > > > > pn0: <82c169 PNIC 10/100BaseTX> rev 0x20 int a irq 11 on pci0.9.0 > > > > What is odd is that the output error metric from netstat -in monotonically > > increases. > > > > Yes, I could post my configuration, etc., and I could go back to running > > -current, but I have a PhD to make progress on. And I'm willing to wait to > > try out the consolidated 2x040/PNIC driver when 4.0 finally rolls out. > > > > > > -scooter > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > > Scott Michel| No research ideal ever survives UCLA Computer Science | contact with implementation. PhD Graduate Student| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP Oddities followup
Scott Michel wrote: > - tcpdump-ing the pn0 interface shows that the host thinks that it's > sending data. tcpdump-ing elsewhere in the network shows that pn0 > isn't actually transmitting anything into the wire. The host appears to be doing retransmissions but nothing goes out on the wire. > - This really is a TCP or interface bug because NFS connections don't > freeze using UDP. It's not just NFS. I can duplicate this behavior with scp and cvsup (things that do bulk data transfer.) -scooter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
TCP Oddities followup
As I'd recently posted on -current, I've been noticing TCP oddities in 3.3 and 3.4. I've got a pn card (NetGear FA310tx) and a few new things to report: - Invariably, a TCP connection will freeze with something in the send queue. Connections don't freeze even if there's something in the receive queue. - tcpdump-ing the pn0 interface shows that the host thinks that it's sending data. tcpdump-ing elsewhere in the network shows that pn0 isn't actually transmitting anything into the wire. - This really is a TCP or interface bug because NFS connections don't freeze using UDP. - Other TCP connections continue to operate (like a cvsup in the background) I haven't stared at the if_pn.c code all that closely but I'm willing to entertain debugging suggestions. -scooter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Odd TCP glitches in new currents
On Wed, 22 Dec 1999, Jonathan Lemon wrote: > On Dec 12, 1999 at 11:37:42AM -0800, Matthew Dillon wrote: > I had a Netgear FS509 switch here that would eat packets transmitted > through the GigE port under certain conditions. Netgear shipped me > a new one, and I've been happy with it, until the same problem started > happening again this morning. There's some oddities in the 3.3 and 3.4 kernels as well -- I've actually nailed down the plexicity and speed on both the Accellar and my humble PC, and yet, I'm looking at weird TCP lockups from time to time. Mostly seems to be related to NFSv3, but will also happen when doing cvsup. There's no magic number of how many bytes are queued waiting to go out the interface. And it seems to be limited to specific connections, i.e. an NFS TCP connection can be jammed and yet I can be happily talking to cvsup3 doing an update. The interface in question is a NetGear: pn0: <82c169 PNIC 10/100BaseTX> rev 0x20 int a irq 11 on pci0.9.0 What is odd is that the output error metric from netstat -in monotonically increases. Yes, I could post my configuration, etc., and I could go back to running -current, but I have a PhD to make progress on. And I'm willing to wait to try out the consolidated 2x040/PNIC driver when 4.0 finally rolls out. -scooter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"oops: 894"
I've got a slightly hosed -current at the moment that complains with this error message: # make oops: 894 followed by a very healthy looking notice about a segfault and because I'm root in single user mode, core dumps are abounding. Since I'm DITW at the moment, anyone got a clue? This Windows thing is not an environment I want to get used to... -scooter (*) I could boot up a 3.2 CD, but solving this 'oops', which looks like a ld.so problem seems pretty important. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel snark, this evening, sup'd ~1800 PDT
A kernel cvsup'd at or about 1800 PDT this evening bought the farm as so: pmap_remove_pages(c3d07924, 0, bfbfe000, c3749034, 1) exec_new_vmspace(c3dafe80, 1, 1, c3dafe80, c025dd5c) exec_elf_imgact(c3d0fe80, c3d02fa0, c025e61c, 0, 1) syscall(...) Xint0x80_syscall(...) I don't have enough disk space to save kernel cores, so I can't give much more that this backtrace. Kernel configuration follows: -- machine "i386" ident MORDRED maxusers10 cpu "I586_CPU" # aka Pentium(tm) options PQ_HUGECACHE options CPU_WT_ALLOC options "NO_F00F_HACK" options "COMPAT_43" options USER_LDT options SYSVSHM options SYSVSEM options SYSVMSG options "MD5" options DDB #optionsDDB_UNATTENDED options KTRACE #kernel tracing options PERFMON options UCONSOLE options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options INET#Internet communications protocols pseudo-device ether #Generic Ethernet pseudo-device loop#Network loopback device pseudo-device bpf 4 #Berkeley packet filter pseudo-device disc#Discard device options TCP_COMPAT_42 #emulate 4.2BSD TCP bugs options MROUTING# Multicast routing # One of these is mandatory: options FFS #Fast filesystem options MFS #Memory File System options NFS #Network File System options NFS_NOSERVER options CD9660 #ISO 9660 filesystem options MSDOSFS #MS DOS File System options PROCFS #Process filesystem options FFS_ROOT#FFS usable as root device options SOFTUPDATES options NSWAPDEV=2 options QUOTA #enable disk quotas options CD9660_ROOTDELAY=20 # NFS options: options NFS_MINATTRTIMO=3 # VREG attrib cache timeout in sec options NFS_MAXATTRTIMO=60 options NFS_MINDIRATTRTIMO=30 # VDIR attrib cache timeout in sec options NFS_MAXDIRATTRTIMO=60 options NFS_GATHERDELAY=10 # Default write gather delay (msec) options NFS_UIDHASHSIZ=29 # Tune the size of nfssvc_sock with this options NFS_WDELAYHASHSIZ=16# and with this options NFS_MUIDHASHSIZ=63 # Tune the size of nfsmount with this #optionsNFS_DEBUG # Enable NFS Debugging options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options _KPOSIX_VERSION=199309L controller scbus0 #base SCSI code device da0 #SCSI direct access devices (aka disks) device da1 device cd0 #SCSI CD-ROMs device pass0 #CAM passthrough driver device pt0 at scbus? #device sctarg0 at scbus? options SCSI_DELAY=8000 # Be pessimistic about Joe SCSI device options CHANGER_MIN_BUSY_SECONDS=2 options CHANGER_MAX_BUSY_SECONDS=10 pseudo-device pty 16 #Pseudo ttys - can go as high as 256 pseudo-device speaker #Play IBM BASIC-style noises out your speaker pseudo-device gzip#Exec gzipped a.out's # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=40960 controller isa0 controller pnp0 options VESA pseudo-device splash device sc0 at isa? options MAXCONS=8 # number of virtual consoles options SC_HISTORY_SIZE=200 # number of history buffer lines device npx0at nexus? port IO_NPX iosiz 0x0 flags 0x0 irq 13 controller fdc0at isa? port "IO_FD1" irq 6 drq 2 diskfd0 at fdc0 drive 0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0at atkbdc? port IO_KBD conflicts irq 12 device sio0at isa? port "IO_COM1" flags 0x10 irq 4 device sio1at isa? port "IO_COM2" flags 0x10 irq 3 device vga0at isa? port ? conflicts device ed0 at isa? port 0x240 irq 10 iomem 0xcc000 # Sound: #device pcm0 at isa? port ? irq 5 drq 3 flags 0x0f controller snd0 device sb0 at isa? port 0x220 irq 5 drq 3 device sbxvi0 at isa? drq 7 device sbmidi0 at isa? port 0x330 controller pci0 controller ncr0 controller ppbus0 device lpt0at ppbus? controller ppc0at isa? port ? irq 7 options CLK_CALIBRATION_LOOP #options"CLK_USE_I8254_CALIBRATION" options CLK_USE_TSC_CALIBRATION options COMPAT_LINUX options NBUF=512 options NMBCLUSTERS=5
Extra characters?
At line 71 in i386/isa/clock.c, there is the following: #include #include XXX #ifdef APIC_IO #include #endif I'd say, and this is only a SWAG mind you, that the 'XXX' is extraneous. Right? -scooter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Just the kind of news we needed...
If you haven't /.'d today, there's a news article purporting that FreeBSD can be exploited via kernel modules: http://thc.pimmel.com/ -scooter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic in spec_strategy()
-current kernel as of 1700 PST (or thereabouts): spec_strategy+0x31: movl0x28(%eax), eax Note: %eax = 0 Traceback: -- spec_strategy(c3d27dd0,c3d27dac,c01cbe1,c3d27dd0,c3d27ddc) at spec_strategy+0x31 spec_vnoperate(c3d27dd0,c3d27ddc,c01d84bb,c3d27dd0,c1b24160) at spec_vnoperate+0x15 ufs_vnoperate(c3d27dd0,c1b24160,12,2,c00e0c40) at ufs_vnoperate+0x15 swstrategy(c1b241b0,e500,c0475c70,c3d27e2c,c01cc872) at swstrategy+0x14f spec_strategy(c3d27e20) at spec_strategy+0x36 swap_pager_putpages(c4340c3c,c3d273ed8,2,0,c3d27e64) at swap_pager_putpages+0x03de default_pager_putpages(c4340c3c,c3d273ed8,2,0,c3d27e64) at default_pager_putpages+0x17 vm_pageout_flush(c3d27ed8,2,0,c014aacd,) at vm_pageout_flush+0x93 vm_pageout_clean(c046ccc40,8000,c01d7868,a000,0) at vm_pageout_clean+0x1e5 vm_pageout_scan(8000,0,0,c0331ff4,c01f5ebc) at vm_pageout_scan+0x44e vm_pageout(0) fork_trampoline... My current config: -- machine "i386" ident MORDRED maxusers10 cpu "I586_CPU" # aka Pentium(tm) options PQ_HUGECACHE options CPU_WT_ALLOC options "NO_F00F_HACK" options "COMPAT_43" options USER_LDT options SYSVSHM options SYSVSEM options SYSVMSG options "MD5" options DDB options KTRACE #kernel tracing options PERFMON options UCONSOLE options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options INET#Internet communications protocols pseudo-device ether #Generic Ethernet pseudo-device loop#Network loopback device pseudo-device bpf 4 #Berkeley packet filter pseudo-device disc#Discard device options TCP_COMPAT_42 #emulate 4.2BSD TCP bugs options MROUTING# Multicast routing options FFS #Fast filesystem options MFS #Memory File System options NFS #Network File System options NFS_NOSERVER options CD9660 #ISO 9660 filesystem options MSDOSFS #MS DOS File System options PROCFS #Process filesystem options FFS_ROOT#FFS usable as root device options SOFTUPDATES options NSWAPDEV=2 options QUOTA #enable disk quotas options CD9660_ROOTDELAY=20 options NFS_MINATTRTIMO=3 # VREG attrib cache timeout in sec options NFS_MAXATTRTIMO=60 options NFS_MINDIRATTRTIMO=30 # VDIR attrib cache timeout in sec options NFS_MAXDIRATTRTIMO=60 options NFS_GATHERDELAY=10 # Default write gather delay (msec) options NFS_UIDHASHSIZ=29 # Tune the size of nfssvc_sock with this options NFS_WDELAYHASHSIZ=16# and with this options NFS_MUIDHASHSIZ=63 # Tune the size of nfsmount with this options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options _KPOSIX_VERSION=199309L controller scbus0 #base SCSI code device da0 #SCSI direct access devices (aka disks) device da1 device cd0 #SCSI CD-ROMs device pass0 #CAM passthrough driver device pt0 at scbus? options SCSI_DELAY=8000 # Be pessimistic about Joe SCSI device options CHANGER_MIN_BUSY_SECONDS=2 options CHANGER_MAX_BUSY_SECONDS=10 pseudo-device pty 16 #Pseudo ttys - can go as high as 256 pseudo-device speaker #Play IBM BASIC-style noises out your speaker pseudo-device gzip#Exec gzipped a.out's options MSGBUF_SIZE=40960 controller isa0 controller pnp0 options VESA pseudo-device splash device sc0 at isa? options MAXCONS=8 # number of virtual consoles options SC_HISTORY_SIZE=200 # number of history buffer lines device npx0at nexus? port IO_NPX iosiz 0x0 flags 0x0 irq 13 controller fdc0at isa? port "IO_FD1" irq 6 drq 2 diskfd0 at fdc0 drive 0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0at atkbdc? port IO_KBD conflicts irq 12 device sio0at isa? port "IO_COM1" flags 0x10 irq 4 device sio1at isa? port "IO_COM2" flags 0x10 irq 3 device vga0at isa? port ? conflicts device ed0 at isa? port 0x240 irq 10 iomem 0xcc000 controller snd0 device sb0 at isa? port 0x220 irq 5 drq 3 device sbxvi0 at isa? drq 7 device sbmidi0 at isa? port 0x330 controller pci0 controller ncr0
Re: net.inet.tcp.always_keepalive on as default ?
> This wouldn't help the poor sod whose connection gets shot down every > eight days while he's not there and doesn't know what hit him. One thing that no one points out is that this "idle" connection is potentially a security threat. Even if the physical connection is iced and is reconnected later using the same IP and the TCP connection is restored because it was kept alive, this presents a whole new world of interesting exploits. It's non-trivial, but that doesn't stop people like Network Associates' Labs from publishing papers on the subject. It seems to me that the keepalive might improve the security situation in the case in addition to doing something about connections with unknown status. The "poor sod" in this situation deserves something untoward, IMNSHO. Protocols like ssh do send something periodically whereas telnet doesn't. Telnet is a well-known security problem. As others have pointed out, this is an endemic problem in applications generally speaking, where a long-term "idle" connection isn't treated as an exception or an an error. Your point on randomization is well taken and is generally what's taught in graduate Internet architecture related courses (ok, Lixia Zhang will drill this into your head here at UCLA, YMMV elsewhere.) Although a more conservative distibution would be [t-t/2, t + 2t]. :-) -scooter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: More compiler option comparisons
I don't recall that the FreeBSD version of egcs is built with Haifa turned on, which is supposed to improve optimizations as the level is increased (more aggressive instruction scheduling.) > With egcs, the '-O' flag doesn't specify the optimization level like it > does in GCC. It specifies the desired stability of the generated code. Lower > numbers (0,1,2) request higher stability. ;) > > DS > > > Dan Nelson wrote: > > > -O4 doesn't exist in egcs (or it didn't a month or so ago). According > > > to the source, -O2 enables all optimizations except -funroll-all-loops, > > > and all -O3 does is enable -funroll-all-loops. > > > > I think I recall reading somewhere that EGCS uses -O numbers > 3 to test > > experimental optimizations. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problems with -current gdb
> % gdb foobar foobar.core > Register %s not found in core file. ^^ Should read: "Register eax not found in core file." Silly me... :-) -scooter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Problems with -current gdb
Current's gdb cannot read core files today (cvsup'd on Monday and installed Monday). It reports: % gdb foobar foobar.core Register %s not found in core file. % The error emanates in gdb/gdb/core-aout.c. I was going to try to diagnose the problem this weekend but unfortunately I have USNR duty. Any pointers, suggestions, etc., when I get back to real life next week? -scooter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Our routed - Vern says it's old and buggy.
"Open" (according to Lenny Kleinrock) meant "available"; thus OSPF was supposed to mean "Available, shortest path first." But, then again, these meanings get changed with time. "Open" is now a codeword for GNU/GPL/intellectual rights unencumbtered software. For OSPF, it was simply a description of an algorithm. The reason for OSPF and link state protocols in the first place was to correct problems that evovled from distance vector protocols, such as "counting to infinity" and to speed convergence when topologies change. Distance vector protocols are easy to implement and easy to understand and easy to configure (i.e. just turn it on.) While link-state doesn't have to be difficult and should be easy to turn on and route, the history of gated has caused a certain mental inertia and prejudice to using them. Heck, even my ex-advisor grimaces with fear when you mention "link-state" in her presence. -scooter > > I can't quite figure why they stuck the word "open" in there, because it > > couldn't possibly be more open than RIP. > > Probably because it was (at the time) in heavy "competition" with the OSI > IS-IS routing protocol. Those standards were *not* openly available. (I > believe they are now.) > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: YP/NIS and passwd weirdness
> Umm- it's never supposed to have been with a '*' in it for this YP > implementation, I believe. Fixing the security check would be a good > thing. Going to pam/nsswitch.conf would be even better. Been that way for years, ever since I started supporting a SCO box oh these many years ago with a UUCP mail link. (System administration in the small company at the time was more than enough motivation to go to graduate school. Where I'm admining Lixia Zhang's machines. :-) Getting an nsswitch.conf-ish type file might not be such a bad thing and would consolidate some of the current set of hacks. -scooter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
YP/NIS and passwd weirdness
I didn't see anything along these lines the the archive, so here goes... (something different to the other threads running these days.) In 3.3.1 and 4.0-current, if one puts the following in /etc/passwd to enable NIS logins: +:*: then logins (console or ssh) of ordinary users don't work. After gdb-ing ssh, I found that getpwnam() consistently returns "*" as the user's password. Removing the "*" makes things work again, but the security check wails about a user w/o a password. Question: Was this intentional behavior or should I submit a pr with a patch? -scooter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS, the time has come...
> Not true IMO. You still need to know what hardware you have before you > can build your own kernels etc etc. > > > Also the eth[0..x] thing means you can replace your ethernet card > > with a new one of a different type without having to look through > > your config code for references to ed0 or whatever. > > True. There's no reason why the devfs code couldn't create the equivalent of symbolic links in its file system so that ed0 and eth0 show up. Yes, I know, this opens up a can of worms when new hardware is added and suddenly the probe order changes such that a newbie finds that eth0 is no longer what he/she/it thought it was going to be. But it's a start. -scooter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS, the time has come...
> I think Solaris (?) requires you to do this, it's called "plumbing > your interfaces" or something (according to Julian). Solaris requires "interface plumbing" as the result of STREAMS; you have to push IP on top of the interface driver. For all intents and purposes, the device name identifies a particular driver (i.e. "le", "qe", "hme", "fa", &c). The number identifies an instance of the device which depends on probe order. [*] Fortunately, the BSD world avoided this particular form of brain damage, thank ! OTOH, as ph--ked as STREAMS happens to be, it does have a certain appeal wrt dynamically building and tearing down network stacks. The AT&T model just didn't have IP in mind when it was designed. -scooter [*] I'd written a hacked version of ifconfig based on the output of 'truss' and managed to get it right in a limited way, as in ifconfig only plumbs IP on top of devices. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
