ipw3945 intel wireless miniPCI
Hi Hackers, Did anyone manage to get this card working under FreeBSD? I'm using FreeBSD 6.1_REL0 on my laptop. I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear to work on 3945. I know about ipw3945.sourceforge.net, there's an opensource stable driver for linux. Any help/tip is greatly appreciated. Thanks. Yours, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipw3945 intel wireless miniPCI
Christian Brueffer wrote: On Thu, Jun 15, 2006 at 05:56:41PM +0300, Alin-Adrian Anton wrote: Hi Hackers, Did anyone manage to get this card working under FreeBSD? I'm using FreeBSD 6.1_REL0 on my laptop. I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear to work on 3945. I know about ipw3945.sourceforge.net, there's an opensource stable driver for linux. Any help/tip is greatly appreciated. Thanks. Unfortunately there is no support in FreeBSD for this chip yet. OpenBSD has support for it in CURRENT in form of the wpi(4) driver. - Christian Thank you for the information. Regards, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh & select() problem on 5.3
Hi, Barney Wolff wrote: Perhaps an MTU problem, with the ICMP "fragmentation needed but DF set" being blocked by the firewall? It would only show up when the server has enough to send to fill a packet. I'm the friend he was talking about. The very same thing happens when the firewall is disabled. I tried from 5.2.1 console and same thing happens. However, we were unable to reproduce the problem on any other servers. It only happens there. No, it's not an ssh bug. I wrote a connect-back snippet and the same thing happens when running commands with relatively big output (like dmesg). I tried logging from 5.2.1 and 5.3 to different servers behind his firewall, running also 5.3 and 5.2.1. The results are similar for all the possible combinations. A tcpdump shows that what actually happens is that packets won't reach me in spite of the fact that his firewall(router)'s tcpdump shows that he keeps sending them to me. Packets never reach me, but I am still able to send them, by pressing ENTER on the ssh console. Interesting fact is that I also get ACK packets for each of the packet I send by pressing ENTER. However this is useless, as the connection is already desynced and I receive no output. The connection times out in 5 minutes. I hope I didn't use a way too obfuscated English. PS: I personally suspect a hardware failure, probably an ethernet card, and he is going to check this out tomorrow. Regards, -- Alin-Adrian Anton Spintech Systems GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock time in milliseconds into a c program
Marco Trentini wrote:
Hi, I need to clock the function execution time into a C
program. I know /usr/include/time.h library but I need to
clock the time in milliseconds.
Any suggestions, links?
---snip---
#include
struct timeval tv1,tv2;
struct timezone tz1,tz2;
gettimeofday(&tv1,&tz1);
for (i=0;i<500;i++) {
tmp=tree_insert(myroot,i,i+10); // cycles
if (tmp) myroot=tmp; // cycles
}
gettimeofday(&tv2,&tz2);
fprintf(stderr,"Insertion of 5 billions lasted %d microseconds\n",
((tv2.tv_sec - tv1.tv_sec) * 100 + (tv2.tv_usec - tv1.tv_usec)));
---snip---
So you can measure the cycles multiple times then compute the average time.
For this snippet (which deals with a B+tree) i got results of the form
0.3445866564 microseconds, which means 344.5867 miliseconds.. etc..
I don't think there is a streight way to speed-up the default unix time
resolution, which is, as far as i know, in microseconds.
Regards,
--
Alin-Adrian Anton
GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E)
gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E
Never ask a man what OS he uses. If it's FreeBSD, he'll tell you.
If it's not, why embarrass him? ..I'm sorry..
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock time in milliseconds into a c program
Erich Dollansky wrote: Hi, Alin-Adrian Anton wrote: For this snippet (which deals with a B+tree) i got results of the form 0.3445866564 microseconds, which means 344.5867 miliseconds.. etc.. You mixed the units up 1 second is 1 000 ms which is 1 000 000 µs which is 1 000 000 000 ns. Yes I noticed. Sorry, been working. -- Alin-Adrian Anton GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E Never ask a man what OS he uses. If it's FreeBSD, he'll tell you. If it's not, why embarrass him? ..I'm sorry.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock time in milliseconds into a c program
Claudiu Dragalina-Paraipan wrote: Or you can use PERFMON. Check manual page for perfmon. It gives you access to internal counters of CPU. Of course this is a subjective measurement, since, AFAIK, the counters are not kept separately for every process, but for entire system, including kernel. Maybe repeating the same measurement for many times, with a system running no other CPU consumers, you will get a more accurate measurement As I said, multiple measurements provide better accuracy. Much better. And as Joseph Koshy pointed out, the RDTSC instruction (works on Pentium i think) may even provide better accuracy then just measuring time. Using it in a cycle of measurements would provide relevant output, and perhaps more accurate then PERFMON (because of direct CPU access). clock_gettime also provides nanoseconds resolution, as pointed out. -- Alin-Adrian Anton GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E Never ask a man what OS he uses. If it's FreeBSD, he'll tell you. If it's not, why embarrass him? ..I'm sorry.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: time and timing errors in c code on 5.x/i386 (longish)
Chris Landauer wrote: some summary output lines that illustrate the problem n46 r08 295.722u 0.417s 5:17.59 93.2% n46 r09 32031.689u 41.815s 9:34:08.17 93.1% n46 r10 5672.848u 2096.191s 635:23:04.54 0.3% (the last column is edited from the output from time in csh; the other two columns are problem parameters, and the mathematics of the problem is such that these values should increase rapidly with increasing r; in this case, the user time has wrapped or otherwise failed in the last line, and since the machine was only running the one program in addition to the usual kde or gnome or something in all 4 cases, it should have been about 93% usage or so like the previous two) i looked at the time structure and it should be big enough to prevent wrapping for some long period of time, but the same thing happens with /usr/bin/time (of course, since it takes a few weeks for each experiment, i didn't do very many of them) - the i/o counts also wrap around, but i don't care about that so i added some code that uses rusage() to the program, and the same failure occurs (my own code for this computation is included next) - a snippet from the time lines in the printed output: user 378925.483628 syst 286.845375 elapse 381328.785295 pct 99.44% user 379089.748458 syst 286.962284 elapse 381493.700660 pct 99.45% user 379255.472355 syst 287.088004 elapse 381660.106387 pct 99.45% user 379417.184286 syst 287.190223 elapse 381822.457863 pct 99.45% user 379417.184286 syst 451.110470 elapse 381986.906692 pct 99.45% user 379417.184286 syst 615.737725 elapse 382152.058304 pct 99.45% [..] i would be happy to perform experiments to solve this problem, and i know that i have to be patient (after all, each experiment takes over two weeks) more later, cal Dr. Christopher Landauer Aerospace Integration Science Center Does this problem occur on another machine? Does it occur on FreeBSD 4.x? Does it occur on another OS? The fact that float = 4 bytes and long = 4 bytes doesn't mean double = long+float. Double datatype takes 8 bytes, yes, but I don't know how many bits are reserved for what, inside the 64 bits. (though this could be digged somewhere). It deals with gcc, probably with system architecture too. I could make suppositions but they are not usefull. You could also try evoyding the scientific notations and the usage of "double" for keeping time, as it is only a matter of +/- one second, as it shows from the code snippet you attached. One second for this matter is so relative, that it is simply irrelevant considering that the accuracy of measuring time inside a C program is itself an aproximation. It deals with an enormous number of factors, where most are incontrolable. So just try keeping time in long format, for seconds. See if it still fails. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E Never ask a man what OS he uses. If it's FreeBSD, he'll tell you. If it's not, why embarrass him? ..I'm sorry.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Rawsock bpf mambo jambo?
And as it has already been said, BPF looks at a lower level than raw sockets. With raw sockets, you are still bound to using IP packets (even if you intentionally create bogus ones). They will be encapsulated in ethernet packets, when the link goes out via ethernet. BPF can be used to read/write ethernet packets too, for example, while raw_sockets cannot. -- Alin-Adrian Anton GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E Never ask a man what OS he uses. If it's a BSD, he'll tell you. If it's not, why embarrass him? ..I'm sorry.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Rawsock bpf mambo jambo?
DJF wrote: Hi everybody, I've recently been looking into raw socket programming. However there's still a question that remains. Maybe it's just a case of RTFM, if so point me to a good manual on the topic. The man pages indicate that you can do read and write operations with rawsock aswell as bpf. However, in all of the source codes I found, a raw socket was used to write to, and bpf was used to read from the interface. http://packetstorm.widexs.nl/programming-tutorials/indexdate.html Search for "raw_tcp.tgz" in that page. What's the advantage in using the rawsock bpf combination instead of bpf (or raw socket) only? Depends on what best fits your development circumstances. The paper I co-authored uses bpf for reading, and socket for writing. Thx in advance, dave -- Alin-Adrian Anton GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E Never ask a man what OS he uses. If it's FreeBSD, he'll tell you. If it's not, why embarrass him? ..I'm sorry.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw2 filtering on bridge
Hi there, I've been running into some problems with what is supposed to be a filtering bridge with IPFW, on FreeBSD 5.4-REL0. IPFW has been compiled into kernel: options BRIDGE options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT along with the bridging capability. No other firewalling mechanisms are enabled. The bridge is configured and working: net.link.ether.bridge.enable=1 net.link.ether.bridge.config=fxp0,vr0 net.link.ether.bridge_ipfw=1 fxp0 is Internet vr0 is a server with an external IP, called EXT_IP I tried blocking with trivial ruleset: 001000 0 deny icmp from any to any 65535 8518 584248 allow ip from any to any However, pinging through the bridge, from the Internet, works without fear: 64 bytes from EXT_IP: icmp_seq=0 ttl=233 time=85.994 ms 64 bytes from EXT_IP: icmp_seq=1 ttl=233 time=96.220 ms If anyone could help me a bit, I'd be really thankfull. Thanks for the time. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw2 filtering on bridge
Ben wrote: I'm sorry, I can't send this to the list because my messages to the list bounce because reverse DNS isn't set up. No worries, thanks a lot for answering. This is funny, I just set this up for the first time yesterday except I set everything up to have no IP addresses so that the firewall would be invisible to anyone. I think I see what is wrong with your setup... You've got to change net.link.ether.bridge_ipfw=1 to net.link.ether.bridge.ipfw=1 in /etc/sysctl.conf. The handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-bridging.html) says that net.link.ether.bridge_ipfw=1 was updated in 5.2-RELEASE. net.link.ether.bridge.enable=1 net.link.ether.bridge.config=fxp0,fxp1 net.link.ether.bridge_ipfw=1 # sysctl net.link.ether.bridge.ipfw=1 net.link.ether.bridge.ipfw: 1 -> 1 # # ipfw add deny icmp from any to any 00100 deny icmp from any to any # # ipfw show 00100 0 0 deny icmp from any to any 65535 931748 651891769 allow ip from any to any # PING EXT_IP_BEHIND_BRIDGE: 56 data bytes 64 bytes from EXT_IP_BEHIND_BRIDGE: icmp_seq=0 ttl=233 time=74.399 ms 64 bytes from EXT_IP_BEHIND_BRIDGE: icmp_seq=1 ttl=233 time=106.194 ms Seems not to be working :( Yours, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
journaling fs and large mailbox format
Dear Hackers, First of all thank you for your time and attention. I am in the position to implement a large-scale mail server and I will never go for anything else but FreeBSD (fixation?). It should be able to handle graceously 4000 e-mail accounts where a minimum of 50 Mb/mailbox would be a requirement. In the begining, it is desirable that users could use as much free space as available, so this implies some gigabytes/mailbox. I don't know if the mbox format can handle this, and I know Maildir cannot handle this on UFS2 standard install, no matter of soft-updates. (because it exhaustes the free nodes) So I currently have no solution for this stuff. I was wondering what is the status of Journaling File Systems on FreeBSD? Any which is usable and mature, with write access? XFS would fit amazingly well with Maildir, but.. I doubt it's anything else but readonly. So any suggestion would really help a lot. Thank's in advance. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
Eric Anderson wrote: Alin-Adrian Anton wrote: I don't know if the mbox format can handle this, and I know Maildir cannot handle this on UFS2 standard install, no matter of soft-updates. (because it exhaustes the free nodes) So I currently have no solution for this stuff. I'm not sure how you came to this conclusion, or what the history is, but I see no reason why UFS2 would have any adverse affects on maildir format mail system. You can set the number of inodes to be created to a higher number when using newfs on the filesystem, so if you believe that is an issue, you should be able to tweak it to your needs. mbox starts to break down on large mailboxes with many messages. 50mb may or may not be in that range, but maildir is much better for performance. I run out of inodes with Maildir, and there were just a few hundred accounts. Outlook ppl tend to "leave their messages on server if they are not 7 days old" and this brings Christmas every day. OK now i received some directions of how to tune it for Maildir, and there's also this link I received: http://www.mostlygeek.com/node/11 A quick note - run the mail area on a RAID array, preferrably a RAID0+1 (or 10 depending on who you ask). Disks are nearly always a bottleneck, so if you can keep your random read/writes fast, the whole system will feel snappy. Defenately. Also there is this: http://www.dbmail.org/ something more appropiate to my principles, however I was told it's not so stable. You might try posting this to freebsd-isp@, since many people there have much larger installations running than this, and can probably provide some good hints. Thanks for the tip. Mike Meyer wrote: > The solution isn't to avoid Maildir/mh - the solution is to tune the file system for the expected usage. Well, I dislike throwing up my problems to a superior level, and act like it was brilliant. It was just running away from the issue, instead of dealing with it. More exactly, storage problems are database theory. Storing the mail is a classic database problem. Throwing this up to the filesystem level is not an elegant way of dealing with it, because now the filesystem must solve it, and this imposes new restrictions to the filesystem. I agree, B-trees are for database index problems, and not only, however, just imagine what would happen if mySQL or PostgreSQL would throw away their database indexing/locking issue up to the filesystem level? It would be a total hoax, one would need separate filesystem tuning for mysql, one for postresql, one for mail, one for apache, etc.. This just brings headaches and unnecessarry restrictions to the partitioning schema. This is why something like dbmail seems more appropiate in my opinion (conceptually). >Neither journaling nor soft updates would solve the problem of running out of inodes. The only solution there is more inodes. XFS may be flexible enough to deal with file systems that far from the norm - but I wouldn't write a business plan based on it without checking first. XFS fits incredibly well with Maildir, however this I did not test practically (i'd need Linux for that :) ). I think having XFS and maybe ReiserFS in BSD is a must (and obviously there must be reasons for being a must, one of them being a large scale Maildir situation), however it's just my opinion. ZCB wrote: >From personal experience on a smaller system(~1000 accounts and nearly all ways less than 45MB boxes) I would suggest avoiding mboxes all together. Maildir is all ways the way to go. For cleaning stuff out automatically and ect, maildir is much nicer as well. Hm ok, thank's for the info. >Also is this vnodes or inodes? See the tuning man pages. For vnodes, there are some sysctls. Inodes. I'll try both tuning the FS and using dbmail, and see what happens. Thank you all. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cwnd and sstresh monitor
Dear Hackers, I would like to monitor the changes of cwnd and sstresh values during TCP traffic, in order to plot graphs and interpret congestion. So I need (cwnd, timestamp) and (sstresh, timestamp) records to be taken everytime one of the two variables is modified. I'd like to ask you for suggestions, which would be the best aproach (kernel patch, kernel module, etc?), and how would this be done best? (the interception of values, the storage of snapshots, etc)? Thanks a lot for your time and valuable informations, I really appreciate any suggestions. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cwnd and sstresh monitor
Robert Watson wrote: On Thu, 1 Dec 2005, Vlad GALU wrote: On 12/1/05, Alin-Adrian Anton <[EMAIL PROTECTED]> wrote: Dear Hackers, I would like to monitor the changes of cwnd and sstresh values during TCP traffic, in order to plot graphs and interpret congestion. So I need (cwnd, timestamp) and (sstresh, timestamp) records to be taken everytime one of the two variables is modified. I'd like to ask you for suggestions, which would be the best aproach (kernel patch, kernel module, etc?), and how would this be done best? (the interception of values, the storage of snapshots, etc)? Does exporting them via sysctl, and graph them using anything (rrdtool) sound reasonable ? I thought about this too, however, this loses precision and provides constant units of time. Knowing the timestamps for each packet may be interesting to underline timeouts on the graphic. I've not used it, but there is a TCPDEBUG kernel option that gathers TCP state information for debugging and tracing purposes. I know this has been used quite effectively in the past for this sort of work, but unfortunately I know very little about it. With all the TCP changes in the last few years (SACK, etc), it could be that it needs some enhancements, cleanups, fixes, etc. I used it now, and with a small patch it shows exactly what I need (seq, ack, timestamp, cwnd and ssthresh). I just added my knob to trpt.c . I also modified the iptime() function to provide microsecond resolution instead of miliseconds, because most of the packets have the same timestamp attached. Still, a decent number of packets have the same timestamp. I'm looking at them only on one side of the connection (the transmitter), I wonder if there is any better solution then timestamping them on both sides - and mixing the values. Thanks guys for the precious information, it helped a lot! Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cwnd and sstresh monitor
Alin-Adrian Anton wrote: I used it now, and with a small patch it shows exactly what I need (seq, ack, timestamp, cwnd and ssthresh). I just added my knob to trpt.c . I also modified the iptime() function to provide microsecond resolution instead of miliseconds, because most of the packets have the same timestamp attached. Still, a decent number of packets have the same timestamp. I'm looking at them only on one side of the connection (the transmitter), I wonder if there is any better solution then timestamping them on both sides - and mixing the values. Thanks guys for the precious information, it helped a lot! Actually the method above had issues, packets not being logged in the debug buffer (which is limited and gets discarded quickly). Using trpt -f did solve this problem, at the cost of duplicate entries. So what finally did the job was a small "patch" of tcp_debug.c to print on console and print only what is needed (FreeBSD 6.0 won't allow "options TCPCONSDEBUG"), and /var/log/messages was parsed to extract the values. Cheers, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Happy new year! (empty body)
I told you it's an empty body, but this is probably why you opened it. Happy new year FreeBSD hackers, and thank you all for your work and efforts. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
which running thread gests the external signal
Hi Hackers, I'm working on a threaded daemon and I'm trying to make it sysadmin friendly. For this, I'm working with external signals. I noticed different behaviour between BSD and Linux for this. When I send an external SIGHUP (rehashing the config file) on BSD the thread receiving the signal seems to be "random". On Linux, if I remeber well, all the threads get the signal, sooner or later.. (the signal handler gets executed as many times as the number of running threads) The tests I've done were done some time ago, this is why I must appologise if I get the chance to mix the memories :|. So just in case anyone already knows (on BSD): which thread gets stopped and moves execution to the signal handler function, when the signal is sent by kill(1) to the pid of the daemon, which is the same for all the threads? (sorry if dizzy speaking) And also, is there a way for delegating one special thread to handle all the external signals? (on BSD) Thanks for the time guys. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: which running thread gests the external signal
Daniel Eischen wrote: POSIX states any thread that is in sigwait() (with the specified signal in the wait mask), or has the signal unmasked (in the threads signal mask) can receive the signal. If you want a certain thread to receive a process-wide signal, then the only sure way (POSIX) to do that is to block the signal in all the threads with the exception of the thread that is to receive the signal. OK, I was able to delegate a single thread for handling all the signals, by using sigprocmask to block all signals at the beggining, then using pthread_sigmask to unblock the needed signals inside the delegated thread. This seemed to be the cleanest way of doing it.. However, this is not fully clean: all the other threads should *ignore* the signals, not *block* them. Blocking a signal means the signal will be queued and the queue will eventually fill, and so on. In my scenario I get the result without running into problems (because each thread seems to have it's own signal queue), however it's not... "clean". The other threads need to simply 'drop' the signals, not cause them to be queued forever (consider an uptime of 1 year?). I don't know the impact, however I want it to be clean.. So ... would it be a way to ignore the signals from all the other threads except the delegated one for handling them? (I'm sorry, I don't notice it, even if it's obvious) Thanks for the advices and the tips, it's been really usefull. PS: Without using sigprocmask and pthread_sigmask, one random thread is stopped in order for the signal handler to execute. Doesn't this mean that the other threads are not 'seeing' the signal? In order to force a thread to receive/see the signal, I need to block the signal inside all the other threads (either with sigprocmask in main, or with pthread_sigmask). On Linux, the signal gets delivered to all the running threads, unless specifically blocked :). And I think that conformes to your mentioning of POSIX standards. Sorry if I'm wrong. [..] I would recommend you also visit http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html I've read it, thanks. I added it to my bookmarks. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: which running thread gests the external signal
Daniel Eischen wrote: You are entirely confused. You should go back to the POSIX standard and get Dave Butenhof's Programming with POSIX Threads book. [..] You are right. All is clear now, i re-read the link twice and played with sigprocmask vs. pthread_sigmask. It's clear now, also with the help of: http://www.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html Thank you very much! (all involved) Regards, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: which running thread gests the external signal
Daniel Eischen wrote: [..] Note that sigprocmask() and pthread_sigprocmask() are equivalent. I don't even think pthread_sigprocmask() is in the standard any longer (it used to be in an older version of the standard). New applications should be using sigprocmask(). Yes I noticed. However, this just happens to be the implementation (probably pthread_sigmask is a wrapper to sigprocmask). This might not be the case on other OS, so for portability I'll stick to the pthread_sigmask in threads, and sigprocmask in single threaded apps. Thanks, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fingerprint Authentication
Cesar wrote: Hello, I was wondering if there are any way to do ssh to a freebsd box and authenticate the user via fingerprint, and/or a module to do http autentication via fingerprint on Apache. Hi, I think this link will be very usefull to you (UPEK fingerprint drivers): http://www.thinkwiki.org/wiki/How_to_enable_the_fingerprint_reader SSH can do pam authentication. Regards, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fingerprint Authentication
Fredrik Lindberg wrote: > > The driver should work fine locally. But using it remote (via ssh etc) > is probably a no-go because verification of the fingerprint records are done by UPEKs driver at the hardware level. > > The only way as I see it (to even make it possible with UPEKs driver) > is to have a reader at both the remote machine and the client machine > and then capture a BioAPI record at the client machine and have the server verify it. But that involves transferring the record in a secure > way to the server. > Or simply have a reader on client side, which if correctly authentificated will issue public-key auth with the server, or sort of.. :) Not really BioAPI auth, but it enables the user to do remote logins by putting the finger on the reader.. -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fingerprint Authentication
Fredrik Lindberg wrote: But that would sort of defeat the whole purpose of biometric authentication and you could really just use public keys instead which would be a lot faster and easier than scanning your finger at each login. :) Unless you locally encrypt your private key with information gathered by the fingerprint reader, as a "password". One can scan his finger only once, at first login, or when the system boots. Passwords are still considered a bit more safe then a fingerprint reader (as far as I know). -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fingerprint Authentication
Fredrik Lindberg wrote: Alin-Adrian Anton wrote: Fredrik Lindberg wrote: But that would sort of defeat the whole purpose of biometric authentication and you could really just use public keys instead which would be a lot faster and easier than scanning your finger at each login. :) Unless you locally encrypt your private key with information gathered by the fingerprint reader, as a "password". That's exactly the problem with, at least, UPEKs driver. If you scan one of your fingers twice you'll get two "different" BioAPI records. That's "different" as in two binary data blobs which aren't equal. To match these records with each other, you hand them over to the driver which, as far as I know, hand them over to the hardware which in turn performs some black magic and then tell you if the records match or not. This is actually the way BSP (Biometric Service Providers..uhh fancy names) modules for BioAPI works. The BSP "captures" a biometric record from somewhere (could be hardware or it could be software), this opaque data is then used to construct a BIR (BioAPI Record) which you store in some database. This process is called "enrollment" in BioAPI-speak. When you want to verify/match a record you let the BSP "capture" a new record (and thus creating a new BIR), you now have two BIRs which aren't bitwise equal and as they are created by a third party module you have no idea of that they contain (except for the BIR header). Then these two BIRs are handed over to the BSP module again for the match process, which will return either a positive or negative result. In UPEKs case I was told by their representative that the matching between two BIRs are done in hardware. In that case, it means the "matching" is a proabilistic distance-computing algorithm. This sux, for any sort of real remote logins. -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
replacing sendmail with qmail
Hi guys, As sendmail showed to be so vulnerable in the past, and even in the recent past, I was wondering to propose removing it from the default install on freebsd. Currently, sendmail comes with the system sources, and runs as root. I think this is bad, and it could be replaced with qmail, for example. Or, something else, if you think something else is more secure. Please let me know if this is possible, or why if not, and to whom shall I address this idea (I wonder why it didn't happen yet). Best Regards, Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
raw socket programming
Hey folks, I am playing with raw sockets on a FreeBSD 4.8 STABLE. This is the include section from my file: #include #include #include #include #include #include #include #include #include When i try to compile the code, this is what I get: %cc -o raw raw.c In file included from raw.c:7: /usr/include/netinet/ip.h:156: syntax error before `n_long' /usr/include/netinet/ip.h:159: syntax error before `n_long' % Errors like that were many more, but I rearranged the included files in this particular order, and the huge number of errors was reduced to what I pasted. Before, there were errors in tcp.h and etc. I would really appreciate an advice of what else to include/not to include in order to get things right. Thanks in advance! Yours Sincerely, Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: raw socket programming
Tom Servo wrote:
Off the top of my head this appears to be an include sequencing/circular
include problem. Check the type that 'n_long' is being defined as and make
sure that the proper includes that define the type are defined before the
variable is defined and make sure that it is not getting run over. Is that
the only files that you are including?
-ts
Hey folks,
I am playing with raw sockets on a FreeBSD 4.8 STABLE. This is the
include section from my file:
#include
#include
#include
#include
#include
#include
#include
#include
#include
When i try to compile the code, this is what I get:
%cc -o raw raw.c
In file included from raw.c:7:
/usr/include/netinet/ip.h:156: syntax error before `n_long'
/usr/include/netinet/ip.h:159: syntax error before `n_long'
%
Errors like that were many more, but I rearranged the included files in
this particular order, and the huge number of errors was reduced to what
I pasted. Before, there were errors in tcp.h and etc.
I would really appreciate an advice of what else to include/not to
include in order to get things right.
Thanks in advance!
Yours Sincerely,
Alin.
Well, I don't wanna be idiot, perhaps I am too tired, but n_long appears
in ip.h defined as :
beast# grep ipt_time /usr/include/netinet/ip.h
union ipt_timestamp {
n_long ipt_time[1];
n_long ipt_time;
} ipt_timestamp;
beast# grep ipt_time /usr/include/netinet/*
/usr/include/netinet/ip.h: union ipt_timestamp {
/usr/include/netinet/ip.h: n_long ipt_time[1];
/usr/include/netinet/ip.h: n_long ipt_time;
/usr/include/netinet/ip.h: } ipt_timestamp;
beast#
And, I simply don't find where ipt_time is defined ! I suppose it is
structure, perhaps it is of type ipt_timestamp, *g*.
And yes, those are all the files I include, nothing more, nothing less.
Alin.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: raw socket programming
Harti Brandt wrote: On Sun, 6 Jul 2003, Alin-Adrian Anton wrote: AA>>>In file included from raw.c:7: AA>>>/usr/include/netinet/ip.h:156: syntax error before `n_long' AA>>>/usr/include/netinet/ip.h:159: syntax error before `n_long' You may want to include harti Yes, indeed this solves the n_long problem. This is how my include list looks now: #include #include #include #include #include #include #include #include #include #include And this is what I get when trying to compile: beast# cc -o raw raw.c In file included from raw.c:7: /usr/include/netinet/ip.h:73: field `ip_src' has incomplete type /usr/include/netinet/ip.h:73: field `ip_dst' has incomplete type /usr/include/netinet/ip.h:158: field `ipt_addr' has incomplete type beast# Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: raw socket programming SOLVED
Harti Brandt wrote: On Sun, 6 Jul 2003, Alin-Adrian Anton wrote: AA>Harti Brandt wrote: AA> AA>>On Sun, 6 Jul 2003, Alin-Adrian Anton wrote: AA>> AA>>AA>>>In file included from raw.c:7: AA>>AA>>>/usr/include/netinet/ip.h:156: syntax error before `n_long' AA>>AA>>>/usr/include/netinet/ip.h:159: syntax error before `n_long' AA>> AA>>You may want to include AA>> AA>>harti AA>> AA>> AA> AA>Yes, indeed this solves the n_long problem. This is how my include list AA>looks now: AA> AA>#include AA>#include AA>#include AA>#include AA>#include AA>#include AA>#include AA>#include AA>#include AA>#include AA> AA>And this is what I get when trying to compile: AA> AA>beast# cc -o raw raw.c AA>In file included from raw.c:7: AA>/usr/include/netinet/ip.h:73: field `ip_src' has incomplete type AA>/usr/include/netinet/ip.h:73: field `ip_dst' has incomplete type AA>/usr/include/netinet/ip.h:158: field `ipt_addr' has incomplete type AA>beast# Try to swap ip.h and in.h (in.h declares struct in_addr). harti Yes, it works now, with these includes: --- #include #include #include #include #include #include #include #include #include #include --- Thank you very much everybody! Best Regards, Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tcp raw socket programming recvfrom()
Hey folks, I wrote my piece of code to play with, and it uses raw sockets to send TCP packets. It sends packets okay, everything tested with a sniffer, everything is really really fine, but it seems I cannot recvfrom anything. I mean, it just keeps waiting and doesn't see the reply the server is actually sending (can be seen with a sniffer). I read that the freebsd kernel does not duplicate any incoming TCP/UDP packets to any of the opened raw sockets. Is that true? So the only solution is to use the interface in promiscuous mode and sniff like a sniffer for the expected packet? Is there any other way? PS: ICMP gets received well with recvfrom (tested). On Linux, it does work for tcp/udp too with recvfrom. I was also wondering if anyone could help me understand why this behaviour in freebsd? (or *BSD) Thanks! Best Regards, Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp raw socket programming recvfrom()
Kip Macy wrote: Usually if your looking at raw packets you want to use BPF. -Kip On Wed, 9 Jul 2003, Alin-Adrian Anton wrote: Hey folks, I wrote my piece of code to play with, and it uses raw sockets to send TCP packets. It sends packets okay, everything tested with a sniffer, everything is really really fine, but it seems I cannot recvfrom anything. I mean, it just keeps waiting and doesn't see the reply the server is actually sending (can be seen with a sniffer). I read that the freebsd kernel does not duplicate any incoming TCP/UDP packets to any of the opened raw sockets. Is that true? So the only solution is to use the interface in promiscuous mode and sniff like a sniffer for the expected packet? Is there any other way? PS: ICMP gets received well with recvfrom (tested). On Linux, it does work for tcp/udp too with recvfrom. I was also wondering if anyone could help me understand why this behaviour in freebsd? (or *BSD) Thanks! Best Regards, Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" Usually? What does usually mean? I know I can use bpf. But is there another way to look at incoming TCP packet ? What I did is I sent a TCP SYN packet and the server answers with a TCP SYN_ACK packet. How can I look at the SYN_ACK packet using raw sockets? Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp raw socket programming recvfrom()
Toni Andjelkovic wrote: On Wed, Jul 09 2003 (12:45:14 +0300), Alin-Adrian Anton wrote: Usually? What does usually mean? I know I can use bpf. But is there another way to look at incoming TCP packet ? What I did is I sent a TCP SYN packet and the server answers with a TCP SYN_ACK packet. How can I look at the SYN_ACK packet using raw sockets? Try libpcap or tcpdump. Cheers, Toni Libcap uses /dev/bpf for *BSD, and RAW recvfrom for linux and others. My goal is to experience with the freebsd system, not only to receive that packet. I just want to understand why *BSD socket model, which is the original socket model, chose not to allow recvfrom with raw sockets, on TCP and UDP protocols. It allows it with ICMP and all others. I just want to understand why this choice. Linux didn't respect that, and in linux it is possible to recvfrom with raw socket, on TCP and UDP protocols too. In the end, I will just use the /dev/bpf to get the work done. I want to play with the system, and understand it, not with a portable lib :P . The goal is not to get things done, for that there is libcap. The goal is to explore src/sys details and IP stack. PS: ethereal is a great sniffer :-) Thanks :-). Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: raw socket programming SOLVED
Wes Peters wrote:
On Saturday 05 July 2003 08:01 pm, Alin-Adrian Anton wrote:
Yes, it works now, with these includes:
---
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
---
Believe it or not, the advice in style(9) is quite helpful in putting
include files in their correct order. I'm so used to doing things in
similar order that I re-wrote your original program as:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main() { printf("foo\n"); }
after grepping for n_long in /usr/include. The order of the netinet
includes; in.h then ip.h then tcp.h, seems logical to me. Perhaps a
(re-) reading of the instructions on include files in style(9) is in
order.
Thank you, I just read it. You are right. :-)
Alin.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New European software patents law !!!
http://petition.eurolinux.org/ sign the petition against the new patents law. find more about this law at http://swpat.ffii.org/ and mirror their website (for load purposes). close your website as did www.gimp.org and protest with banners, and in any other way. God bless the virus industry. Yours, Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: server rebooted
[EMAIL PROTECTED] wrote: Hello. I have a dedicated server the one was up for more than 84 days but this Friday 19, suddenly the server was rebooted. this is the output of the "last" command # last | grep reboot reboot ~ vie 19 sep 13:55 I already have check the logs but i can't found any hint that could help me to know why the server as was rebooted. Any idea on what to check or how to know what makes the server to reboot? thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" Check all the logs, not only the lastlog. Start with /var/log/messages, and continue there. See behaviour of all the installed daemons and what did they log. If the kernel is not debug-enabled, there are chances you won't find out certain crashes. A power-off problem will be noticed because of disrupted timestamps in the logs, and no shutting down messages from the daemons and the kernel. And if you don't CAREFULLY and PATIENTLY find anything in the logs, check them for intrusion, if you have some other logging device in the network check that one too for weird traffic etc. But I think I'm paranoid :PpPp Alin. smime.p7s Description: S/MIME Cryptographic Signature
Re: porting linux SOCK_RAW to freebsd
Andy Hilker wrote:
Hi,
i try porting a little utility from linux to freebsd.
Maybe someone could give me a hint, what i am doing wrong.
-- snip --
/* Note: not portable */
// if ((s = socket(AF_INET, SOCK_PACKET, SOCK_PACKET)) < 0) {
// ??? ported
if ((s = socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) < 0) {
if (errno == EPERM)
fprintf(stderr, "programm must run as root\n");
else
perror("programm: socket");
if (! debug)
return 2;
}
/* Fill in the source address, if possible.
The code to retrieve the local station address is Linux specific. */
/* Note: not portable */
/*
if (! opt_no_src_addr){
struct ifreq if_hwaddr;
unsigned char *hwaddr = ifr_addr.sa_data;
strcpy(if_hwaddr.ifr_name, ifname);
if (ioctl(s, SIOCGIFHWADDR, &if_hwaddr) < 0) {
fprintf(stderr, "SIOCGIFHWADDR on %s failed: %s\n", ifname,
strerror(errno));
return 1;
}
memcpy(outpack+6, if_hwaddr.ifr_hwaddr.sa_data, 6);
if (verbose) {
printf("The hardware address (SIOCGIFHWADDR) of %s is type %d "
"%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n", ifname,
if_hwaddr.ifr_hwaddr.sa_family, hwaddr[0], hwaddr[1],
hwaddr[2], hwaddr[3], hwaddr[4], hwaddr[5]);
}
}
*/
// ??? ported, xx:xx:xx:xx:xx:xx = MAC Adress of sender
memcpy(outpack+6, "xx:xx:xx:xx:xx:xx", 6);
/* Note: not portable */
/*
whereto.sa_family = 0;
strcpy(whereto.sa_data, ifname);
if ((i = sendto(s, outpack, pktsize, 0, &whereto, sizeof(whereto))) < 0)
perror("sendto");
else if (debug)
printf("sendto returned %d.\n", i);
*/
// ??? ported, fxp0 = sending interface
whereto.sa_family = 0;
strcpy(whereto.sa_data, "fxp0");
if ((i = sendto(s, outpack, pktsize, 0, &whereto, sizeof(whereto))) < 0)
perror("sendto");
else if (debug)
printf("sendto returned %d.\n", i);
-- snip --
bye,
Andy
I wrote a paper on FreeBSD raw sockets a while ago. You can find it here:
http://www.reversedhell.net/rawsockets/raw_tcp.tgz
or here:
http://packetstormsecurity.org/programming-tutorials/raw_tcp.tgz
Cheers/bye,
Alin.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
