simple tcp question (syn, no mss)
Will I ever see a _legitimate_ packet in the wild that is a SYN, and has no MSS ? If the answer is no, then is this a good rule to block those: ipfw add 1 deny tcp from any to any tcpflags syn tcpoptions !mss Or is this one better: ipfw add 2 deny tcp from any to any setup tcpoptions !mss - I am simply trying to place a rule which blocks those packets and does not deny _any_ legitimate traffic (I don't consider nmapping to be legit for this discussion) - this is all provided that I am correct that there are no _legitimate_ packets in the wild that have a SYN and no MSS. thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
determining inserted floppy size
Hi, I'm trying to write a kind of 'floppy dump' program, and therefore I would like to know if it is possible to determine the size of the floppy inserted into the drive. ioctl(fd, FD_GTYPE) gives me the type of the *drive* which is not what I want, ioctl(fd, DIOCGDINFO) doesn't work because there is no disklabel, and looking through /sys/isa/fd.c doesn't give me a further clue either. Is this not possible? --Stijn -- ] Nothing safer than a 'cat /dev/wallet | grep $price real-person; \ ] mv $thing-to-buy $my-case I'd prefer 'mv $thing-to-buy $my-case cat /dev/wallet | \ grep $price real-person -- Anonymous, [EMAIL PROTECTED], in message [EMAIL PROTECTED] msg39209/pgp0.pgp Description: PGP signature
Re: 5.0 DP2 fixit.flp woes
I've run a few more tests on the floppy drive, especially on Windows NT I realise that the errors point to a faulty drive so I have a new one on order. It has not arrived yet. I'm not yet convinced that the drive is at fault. To summarise, I get errors on some of the installation floppies if accessed as a FreeBSD file system. It is ok if accessed as raw read and write, or using Windows NT. kern, fixit, mfsroot and drivers floppies are from 5.0 DP2 cdrom. Summary === OK fdformat -v FAILfsck /dev/fd0 on fixit floppy OK fsck /dev/fd0 on mfsroot floppy FAILfsck /dev/fd0 on drivers floppy FAILfixit, mount on /mnt and tar cvf testtar /mnt FAILfixit, mount on /mnt and find /mnt OK boot up on kern floppy, load mfsroot and use sysinstall FAILboot up on kern floppy, load mfsroot and use fixit floppy OK dd if=/dev/fd0 OK mcopy (part of mtools package) large files to and from a MSDOS floppy OK Windows NT, copy hundreds of small files to and from a subdirectory on an MSDOS floppy. This involves lots of seeks. FAILmcopy hundreds of small files from MSDOS floppy (created by NT) FAILmount -t msdos /dev/fd0 and cp hundreds of file from MSDOS floppy as created by NT OK Windows NT, format a: To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: /rescue
.PATH?? Hmmm... I must have missed that one. I'll take a look; maybe it will simplify some things. Thanks for the pointer. Tim M. Warner Losh wrote: I'm curious why you did things this way, rather then with .PATH in the makefile? Warner *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/exec.c Mon Dec 9 21:56:20 2002 *** *** 0 --- 1 + #include ../../lib/libc/gen/exec.c *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/getusershell.c Fri Dec 27 17:38:14 2002 *** *** 0 --- 1 + #include ../../lib/libc/gen/getusershell.c *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/login_class.c Thu Jan 2 22:50:40 2003 *** *** 0 --- 1 + #include ../../lib/libutil/login_class.c *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/popen.c Fri Dec 27 17:38:35 2002 *** *** 0 --- 1 + #include ../../lib/libc/gen/popen.c *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/rcmdsh.c Fri Dec 27 17:38:49 2002 *** *** 0 --- 1 + #include ../../lib/libc/net/rcmdsh.c *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/sysctl.c Wed Jan 8 19:39:38 2003 *** *** 0 --- 1 + #include ../../lib/libc/gen/sysctl.c *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/system.c Fri Dec 27 17:37:49 2002 *** *** 0 --- 1 + #include ../../lib/libc/stdlib/system.c *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/rescue/Makefile Wed Jan 8 20:25:05 2003 *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mac iBook OS10 + BSD
void writes:
Also, X11 feels quite slow if you're
used to X11. (I'm writing this from KDE running under XDarwin on a ti
powerbook, 867MHz).
Apple's new X11-for-Mac-OS-X beta software is much faster than XDarwin.
Much buggier too. And it lacks full screen mode.
I've dropped back to just using ctwm and XDarwin. Aqua is all the
eye-candy one man can stand, kde on top is just overkill.
FWIW, the only config I've found which allows cut and paste between X
and Aqua is XDarwin+{C}TWM, or Apple's X11 which uses their hideous
Aqua-like WM... Half the reason I use X rather than a bunch of
terminals is to *avoid* the clunky, non-custamizable UI that the Aqua
interface gives you..
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: simple tcp question (syn, no mss)
why don't you put in a rule to catche them and count them. then after a day or two you can go see how many there were.. On Wed, 15 Jan 2003, Josh Brooks wrote: Will I ever see a _legitimate_ packet in the wild that is a SYN, and has no MSS ? If the answer is no, then is this a good rule to block those: ipfw add 1 deny tcp from any to any tcpflags syn tcpoptions !mss Or is this one better: ipfw add 2 deny tcp from any to any setup tcpoptions !mss - I am simply trying to place a rule which blocks those packets and does not deny _any_ legitimate traffic (I don't consider nmapping to be legit for this discussion) - this is all provided that I am correct that there are no _legitimate_ packets in the wild that have a SYN and no MSS. thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Opting For It24664
BioCurex PRESS RELEASE Source: BioCurex, Inc. January 9, 2003 OTCBB Listed BioTech Companies BOCX RJVN - Creating a Non-Toxic Therapeutic Antibody Cancer Treatment That May Arrest Development and Replication of Cancerous Cells. Rancho Santa Margarita, Calif., January 9, 2003 BioCurex, Inc., (OTC BB:BOCX), Announces further developments relating to its licensing agreement with BioKinetix, a company being acquired by RJV Networks, Inc., (OTC BB : RJVN). BioCurex and RJV networks (through Biokinetix) are behind the development of a new therapeutic product, which experts believe will arrest the development of and replication of cancerous cells that cause the growth of malignant tumors. BOCX's proprietary technology has identified a New Widespread Cancer marker Molecule named RECAF. Cancer markers are molecules that appear on cancer cells but not on normal cells and have been hailed as The Holy Grail of cancer research since they can be used to detect (diagnose) and then specifically target cancer cells (therapy) - offering the potential to provide treatment of cancer by delivering antibodies to the targeted cancerous cells. RJVN and BioKinetics have proprietary technology for developing superantibodies, an enhancement of antibody technology that makes ordinary antibodies much more lethal. The combination of anti-RECAF antibodies from BioCurex with the superantibody technology from RJVN - BioKinetics is expected to produce a powerful therapeutic agent to combat most types of cancer. If the antibodies prove to be cancer cell specific, it is unlikely that there would be any adverse side effects. This lack of toxicity should accelerate testing and approval process. Dr. Moro, President of Biocurex stated: Our ultimate goal is to fight cancer. We have the cancer marker that identifies the cancer cells and RJV Networks-BioKinetix has the superantibody technology to kill them. It is only natural that we join forces in the battle against this horrible disease. I see tremendous potential for success in this joint effort. Dr. John Todd, President of BioKinetix Corporation stated that Bio Kinetix Corporation's mission is to acquire intellectual property rights for existing products and intellectual property. Then, through a series of collaborative relationships, we will facilitate the development of a new generation of monoclonal antibodies (termed Superantibodies), which will have a significantly improved therapeutic potency as anticancer agents. BioCurex, Inc. Richard Moro, President RJV Networks-BioKinetix Grant Young For more info see RJVN and BOCX in the news. You can also see this Press Release at Yahoo Finance biz.yahoo.com/pz/030109/35412.html You can also look them up by their symbols: OTC BB:BOCX or OTC BB : RJVN Special Financial-Stock Opt-in mailing list Offer As a member of our special opt-in mailing list, you will be among the first to receive up to the minute information regarding the companies we profile above as well as a free 10-day trial to a website with real-time Level II quotes, research reports, OTC BB promo / syndication calendar, trading chat rooms, full threading message boards, along with many other valuable and free investment tools not readily available to the general public. This is an incredible opportunity! Just click the link below to send us an email, and you will be immediately added to our Opt-in list. Please be sure that opt-in is in the subject line of the email. If opt-in is not in the subject line you will not be added. MailTo:[EMAIL PROTECTED]?Subject=Opt-In Thank you. **See Removal instructions below ***Disclaimer Information within this email contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be forward looking statements. Forward looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as: projects, foresee, expects, estimates, believes, understands will, anticipates, or that by statements indicating certain actions may, could, or might occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this
Re: simple tcp question (syn, no mss)
Yes, I did that :) Take a look: 1 15554624172 count tcp from any to any setup tcpoptions !mss 2 16475664738 count tcp from any to any tcpflags syn tcpoptions !mss 33743453 196847392 count tcp from any to any setup So ... 1/296th of all my setup (syn, no ack) packets have no mss. Actually the number is even smaller since I put the first two rules in place about an hour or so before the third rule... Also, I can support the notion that any remaining non-DoS packets that are setup (syn, no ack) and have no mss are indeed work packets. I ran this tcpdump line: tcpdump -vvv -n | grep S | grep -v mss | more and all I got were random connections to port 80, 1080, and 8080 over and over again. Sometimes they would scan over consecutive IPs on my end, and sometimes they would just be random IPs on my end - but they look like worm packets nonetheless. So I have decided I am going to put in one of he above two block rules ... I think I have mostly windows and linux 2.x users anyway, so I am not going to be denying anyone. I have one last question - why are the numbers (count) of these two rules different: 1 15554624172 count tcp from any to any setup tcpoptions !mss 2 16475664738 count tcp from any to any tcpflags syn tcpoptions !mss The first rule says any syn!ack packets (setup) that have no mss, and there are apparently about 7% less packets that match this than match simply having SYN (and who knows what other flags) and no mss. Comments as to why these numbers are different, and what _additional_ things get blocked by rule #2 ? thanks. On Wed, 15 Jan 2003, Julian Elischer wrote: why don't you put in a rule to catche them and count them. then after a day or two you can go see how many there were.. On Wed, 15 Jan 2003, Josh Brooks wrote: Will I ever see a _legitimate_ packet in the wild that is a SYN, and has no MSS ? If the answer is no, then is this a good rule to block those: ipfw add 1 deny tcp from any to any tcpflags syn tcpoptions !mss Or is this one better: ipfw add 2 deny tcp from any to any setup tcpoptions !mss - I am simply trying to place a rule which blocks those packets and does not deny _any_ legitimate traffic (I don't consider nmapping to be legit for this discussion) - this is all provided that I am correct that there are no _legitimate_ packets in the wild that have a SYN and no MSS. thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
trying to create a port of gnotime
Hi all, I am trying to make a port of gnotime ( http://sourceforge.net/projects/gttr/ ) and I am hitting a few problems. I checked how other GNOME ports work and think I used all the right flags. When I try to build, I get the following output (appended) I have other gnome apps that build fine. The listed dependencies for gnotime (according to their readme) are libgnome and libgnomeui, so I installed that first. BTW, is it correct to list those in the LIB_DEPENDS flag ? I found no USE_GNOME label corresponding to these libs. If anybody with some experience building gnome apps can spot what is wrong here, I'd be grateful for the help... bruno root@duron:/usr/ports/finance/gnotimemake === Extracting for gnotime-2.1.5_1 Checksum OK for gnotime-2.1.5.tar.gz. === gnotime-2.1.5_1 depends on executable: libtool - found === gnotime-2.1.5_1 depends on shared library: guile.10 - found === gnotime-2.1.5_1 depends on shared library: gnomeui - found === gnotime-2.1.5_1 depends on shared library: X11.6 - found === gnotime-2.1.5_1 depends on shared library: esd.2 - found === gnotime-2.1.5_1 depends on shared library: ghttp.1 - found === gnotime-2.1.5_1 depends on shared library: glib12.3 - found === gnotime-2.1.5_1 depends on shared library: gtk12.2 - found === gnotime-2.1.5_1 depends on shared library: xml.5 - found === gnotime-2.1.5_1 depends on shared library: gdk_pixbuf.2 - found === gnotime-2.1.5_1 depends on shared library: Imlib.5 - found === gnotime-2.1.5_1 depends on shared library: ORBit.2 - found === gnotime-2.1.5_1 depends on shared library: gnome.5 - found === gnotime-2.1.5_1 depends on shared library: gnomecanvaspixbuf.1 - found === gnotime-2.1.5_1 depends on shared library: oaf.0 - found === gnotime-2.1.5_1 depends on shared library: gconf-1.1 - found === gnotime-2.1.5_1 depends on shared library: capplet.5 - found === gnotime-2.1.5_1 depends on shared library: gnomeprint.16 - found === gnotime-2.1.5_1 depends on shared library: bonobo.2 - found === gnotime-2.1.5_1 depends on shared library: gda-client.0 - found === gnotime-2.1.5_1 depends on shared library: gnomedb.0 - found === gnotime-2.1.5_1 depends on shared library: glade.4 - found === gnotime-2.1.5_1 depends on shared library: gal.21 - found === gnotime-2.1.5_1 depends on shared library: glibwww.1 - found === gnotime-2.1.5_1 depends on shared library: gtkhtml-1.1.3 - found === Patching for gnotime-2.1.5_1 === Configuring for gnotime-2.1.5_1 configure: WARNING: you should use --build, --host, --target checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking whether make sets $(MAKE)... yes checking for working aclocal-1.4... missing checking for working autoconf... found checking for working automake-1.4... missing checking for working autoheader... found checking for working makeinfo... found checking for perl... /usr/bin/perl checking whether to enable maintainer-specific portions of Makefiles... no checking for i386-portbld-freebsd4.6-gcc... cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for strerror in -lcposix... no checking for i386-portbld-freebsd4.6-g++... c++ checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking for i386-portbld-freebsd4.6-gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) yes checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking how to run the C preprocessor... cc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for bison... bison -y checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking what warning flags to pass to the C compiler... checking what language compliance flags to pass to the C compiler... checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for Guile... yes checking for pkg-config... /usr/local/bin/pkg-config checking for libgnome-2.0 = 2.0.0 libgnomeui-2.0 = 2.0.3... yes checking GNOTIME_CFLAGS... -DORBIT2=1 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/orbit-2.0 -I/usr/local/include/libbonobo-2.0 -I/usr/local/include/linc-1.0 -I/usr/local/include/bonobo-activation-2.0
Re: trying to create a port of gnotime
SOLVED! turns out I had a (I suppose obsolete ) directory /usr/X11R6/include/gdk-pixbuf that was conflicing with /usr/X11R6/include/gtk-2.0/gdk-pixbuf/ port coming along fine now... submitting soon bruno On Wed, 15 Jan 2003, bruno schwander wrote: Hi all, I am trying to make a port of gnotime ( http://sourceforge.net/projects/gttr/ ) and I am hitting a few problems. I checked how other GNOME ports work and think I used all the right flags. When I try to build, I get the following output (appended) I have other gnome apps that build fine. The listed dependencies for gnotime (according to their readme) are libgnome and libgnomeui, so I installed that first. BTW, is it correct to list those in the LIB_DEPENDS flag ? I found no USE_GNOME label corresponding to these libs. If anybody with some experience building gnome apps can spot what is wrong here, I'd be grateful for the help... bruno To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB problem on A7N266-VM MoBo
On Mon, Jan 13, 2003 at 12:51:39PM +1300, James Pole wrote: On Mon, 2003-01-13 at 10:41, Guido Falsi wrote: I'm using FreeBSD on the Mother Board in the subject, and I am experiencing the following problem with USB devices(tired with a memory stick and a joystick, can try other devices if necessary): When I attach the device for the first time there is no problem, I get the expected reaction, but when I detach it, the detachment is not detecte, the system simply thinks the device is still there. If I then try to reattach the device the system does not notice the attach anymore. Does this problem happen in any other OSes? This sounds to me like a hardware problem and not a software problem. To be honest it's probably a problem with the RELENG_4 USB stack. It doesn't work very well on some chipsets. The one in 5.x is much better. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = msg39218/pgp0.pgp Description: PGP signature
