Re: linux PF_PACKET compatibility
On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: linux PF_PACKET compatibility
On Fri, Feb 11, 2011 at 9:22 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org Take a look at bpf(4). I believe you could bypass the TCP/IP stack with netgraph(4), as well, although with possibly more overhead. -- Good, fast cheap. Pick any two. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: linux PF_PACKET compatibility
On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: linux PF_PACKET compatibility
On Fri, Feb 11, 2011 at 11:36 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) I suppose you could just use mpd :) -- Good, fast cheap. Pick any two. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
Hi, during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. Here is the list of affected files (for those impatient ones which do not want to look at the attached patch before noticing that they are not interested to look at it): ---snip--- cam/cam.c fs/nfsclient/nfs_clvfsops.c fs/nfsserver/nfs_nfsdport.c kern/kern_dtrace.c kern/kern_ktr.c kern/kern_ktrace.c kern/kern_lock.c kern/kern_lockstat.c kern/kern_ntptime.c kern/kern_pmc.c kern/kern_prot.c kern/ksched.c kern/subr_mchain.c kern/subr_stack.c kern/sysv_msg.c kern/sysv_sem.c kern/sysv_shm.c kern/uipc_cow.c kern/uipc_mqueue.c kern/uipc_sem.c nfsclient/nfs_vfsops.c nfsserver/nfs_serv.c security/audit/audit.c security/mac/mac_syscalls.c ---snip--- Thanks, Alexander. -- Most people in this society who aren't actively mad are, at best, reformed or potential lunatics. -- Susan Sontag http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Index: cam/cam.c === --- cam/cam.c (Revision 218482) +++ cam/cam.c (Arbeitskopie) @@ -51,6 +51,9 @@ #include sys/libkern.h #include cam/cam_queue.h #include cam/cam_xpt.h + +FEATURE(scbus, SCSI devices support); + #endif static int camstatusentrycomp(const void *key, const void *member); Index: fs/nfsclient/nfs_clvfsops.c === --- fs/nfsclient/nfs_clvfsops.c (Revision 218482) +++ fs/nfsclient/nfs_clvfsops.c (Arbeitskopie) @@ -73,6 +73,8 @@ #include fs/nfsclient/nfs.h #include fs/nfsclient/nfsdiskless.h +FEATURE(nfscl, NFSv4 client); + extern int nfscl_ticks; extern struct timeval nfsboottime; extern struct nfsstats newnfsstats; Index: fs/nfsserver/nfs_nfsdport.c === --- fs/nfsserver/nfs_nfsdport.c (Revision 218482) +++ fs/nfsserver/nfs_nfsdport.c (Arbeitskopie) @@ -46,6 +46,8 @@ #include nlm/nlm_prot.h #include nlm/nlm.h +FEATURE(nfsd, NFSv4 server); + extern u_int32_t newnfs_true, newnfs_false, newnfs_xdrneg1; extern int nfsrv_useacl; extern int newnfs_numnfsd; Index: kern/kern_dtrace.c === --- kern/kern_dtrace.c (Revision 218482) +++ kern/kern_dtrace.c (Arbeitskopie) @@ -37,10 +37,14 @@ #include sys/malloc.h #include sys/proc.h #include sys/dtrace_bsd.h +#include sys/sysctl.h #define KDTRACE_PROC_SIZE 64 #define KDTRACE_THREAD_SIZE 256 +FEATURE(kdtrace_hooks, +Kernel DTrace hooks which are required to load DTrace kernel modules); + MALLOC_DEFINE(M_KDTRACE, kdtrace, DTrace hooks); /* Return the DTrace process data size compiled in the kernel hooks. */ Index: kern/kern_ktr.c === --- kern/kern_ktr.c (Revision 218482) +++ kern/kern_ktr.c (Arbeitskopie) @@ -80,6 +80,8 @@ #define KTR_CPU PCPU_GET(cpuid) #endif +FEATURE(ktr, Kernel support for KTR kernel tracing facility); + SYSCTL_NODE(_debug, OID_AUTO, ktr, CTLFLAG_RD, 0, KTR options); int ktr_cpumask = KTR_CPUMASK; Index: kern/kern_ktrace.c === --- kern/kern_ktrace.c (Revision 218482) +++ kern/kern_ktrace.c (Arbeitskopie) @@ -83,6 +83,8 @@ #ifdef KTRACE +FEATURE(ktrace, Kernel support for system-call tracing); + #ifndef KTRACE_REQUEST_POOL #define KTRACE_REQUEST_POOL 100 #endif Index: kern/kern_lock.c === --- kern/kern_lock.c (Revision 218482) +++ kern/kern_lock.c (Arbeitskopie) @@ -1299,6 +1299,10 @@ } #ifdef INVARIANT_SUPPORT + +FEATURE(invariant_support, +Support for modules compiled with INVARIANTS option); + #ifndef INVARIANTS #undef _lockmgr_assert #endif Index: kern/kern_lockstat.c === --- kern/kern_lockstat.c (Revision 218482) +++ kern/kern_lockstat.c (Arbeitskopie) @@ -39,7 +39,10 @@ #include sys/time.h #include sys/types.h #include sys/lockstat.h - +#include sys/param.h +#include sys/sysctl.h +#include sys/kernel.h +FEATURE(kdtrace_hooks, Kernel DTRACE hooks); /* * The following must match the type definition of dtrace_probe. It is * defined this way to avoid having to rely on CDDL code. Index: kern/kern_ntptime.c === --- kern/kern_ntptime.c (Revision 218482) +++ kern/kern_ntptime.c (Arbeitskopie) @@ -51,6 +51,10 @@ #include sys/syscallsubr.h #include sys/sysctl.h +#ifdef PPS_SYNC
Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
On Friday, February 11, 2011 4:30:28 am Alexander Leidinger wrote: Hi, during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. Here is the list of affected files (for those impatient ones which do not want to look at the attached patch before noticing that they are not interested to look at it): Hmm, so what is the rationale for adding FEATURE() macros? Do we just want to add them for everything or do we want to add them on-demand as use cases for each knob arrive? Some features can already be inferred (e.g. if KTR is compiled in, then the debug.ktr.mask sysctl will exist). Also, in the case of KTR, I'm not sure that any userland programs need to alter their behavior based on whether or not that feature was present. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: linux PF_PACKET compatibility
On 02/11/11 19:54, Vlad Galu wrote: On Fri, Feb 11, 2011 at 11:36 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au mailto:freebsd-hack...@herveybayaustralia.com.au wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) I suppose you could just use mpd :) I could, I guess. But where's the fun in that? :) Seriously, though, mpd didn't quite cut it (I thought) for me. I need a l2tp vpn server with the capability to handle multiple clients with only one interface. The server is behind a firewall, and I'm trying for a walled garden variety I guess. So far my research has brought me here, but I'm open to suggestions. One other that has my attention is l2tpd (in ports). I want radius auth, so IF I can use pppd in base and radius (which as I understand- so far anyway- it needs), and only uses a single interface, then maybe. I'm still hunting and playing- learning on the fly. From what I read mpd uses an ng interface for every single client. L2tpns doesn't, and from what I've read so far neither does l2tpd (I was actually looking at another fork of that xl2tpd). I could use some advice from someone with experience with this, but my feelers on -questions didn't get much response. I may try on -net if this fails... Aside from that I also wanted to get a bit more of a hands on feel for the FreeBSD core. I can't sit on the sidelines yelling at the players any more :) I'm not much for spectator sport either... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
Quoting John Baldwin j...@freebsd.org (from Fri, 11 Feb 2011 07:51:52 -0500): On Friday, February 11, 2011 4:30:28 am Alexander Leidinger wrote: Hi, during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. Here is the list of affected files (for those impatient ones which do not want to look at the attached patch before noticing that they are not interested to look at it): Hmm, so what is the rationale for adding FEATURE() macros? Do we just want to add them for everything or do we want to add them on-demand as use cases for each knob arrive? Some features can already be inferred (e.g. if KTR is The non-answer is: IMO we want to add as much as needed. See below for an explanation. compiled in, then the debug.ktr.mask sysctl will exist). Also, in the case of KTR, I'm not sure that any userland programs need to alter their behavior based on whether or not that feature was present. The main goal was to have an easy way (e.g. not a lot of parsing) without sideeffects (e.g. autoloading of kernel modules) to query if a feature is available. Regarding this, there is no need to have one for KTR. The 2nd goal is (as you know, as we discussed it in the beginning of the GSoC) to be able to hide a feature administratively (I plan to commit the userland part regarding this last). You can not do this with sysctl, so for me adding a FEATURE for KTR provides more possibilities. I see a use case for this in KTR, an app may see if it is there and start some tracing based upon it (and it could be adminsitratively prohibited by hiding the presence), or there could be a sanity check in a script which prevents some tracing-setup to happen if it is not there (or administratively hidden). In general I do not want to decide if something makes sense for an app or not, as I do not think I can come up with all possible use cases (possibilities instead of policies). As such it makes sense to add more FEATURE macros to the tree than what we have ATM. If used correctly (via the to be committed userland part), this may make the life of some people more easy. As a 3rd point (attention bikeshed ahead), having everything as a FEATURE would give an uniform way of listing what is available or not (with the benefit to administratively hide parts of it). Needless to say that this would reduce the amount of knowledge and code to determine if something is available (as a person who works in a production environement with mixed knowledge levels of the people and who has to analyse problems which are sometimes caused by lack of knowledge of the people which implemented something, I welcome everything which lowers the learning curve and complexity). Bye, Alexander. -- It wasn't exactly a divorce -- I was traded. -- Tim Conway http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
Hi Devin, Thanks for sharing your work. The list strips non-text attachments so there isn't much to see at the moment though... --- Fleuriot Damien On 11 Feb 2011, at 04:53, Devin Teske dte...@vicor.com wrote: Hi All, I'd like to announce the release of a new script. A script that I've developed for our field engineers that I'd like to share with the rest of the world. http://druidbsd.sourceforge.net/download/host-setup.txt host-setup(1) is a dialog(1)-based utility (written in sh(1)) designed to make configuring FreeBSD more efficient. We have this script configured to be run as root's initial login immediately after first-boot. The field engineer uses our custom installer to install RELENG_8, and after the machine presents a login prompt, they login with the pre-configured root password. After which they are presented with this dialog (image attached: host-setup.pub.png). The dialogs should all be intuitive, and I hope that you like my work. I've worked very hard to make this utility smooth, robust, fault-tolerant and even enjoyable to use. Not only that, but it helps prevents mistakes that could arise in doing these steps by-hand (like forgetting to unmount active NFS-mounts before executing route flush). Please give it a try and let me know what you think. -- Devin P.S. This is not a trivial script. ``More nuclear reactor than bike shed'' ^_^ P.P.S. Should be backward compatible to RELENG_4. P.P.S. I know the screenshot says host-setup.pub -- that's only because our in-house-only version has more functionality than the one I'm releasing to the general public today (no functionality that anyone in the public audience would ever care about though). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
On Fri, 11 Feb 2011 08:56:42 +0100 Damien Fleuriot m...@my.gd wrote: The list strips non-text attachments so there isn't much to see at the moment though... It wasn't supposed to be attached - try http://druidbsd.sourceforge.net/download/host-setup.txt :) -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
problem with build mcelog
Hello. i am trying build mcelog FreeBSD 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14 04:15:56 UTC 2011 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 # fetch http://ftp2.pl.freebsd.org/pub/FreeBSD/distfiles/mcelog-1.0pre2.tar.gz # tar -xf mcelog-1.0pre2.tar.gz # cd mcelog-1.0pre2 # fetch http://people.freebsd.org/~jhb/mcelog/mcelog.patch # fetch http://people.freebsd.org/~jhb/mcelog/memstream.c # patchmcelog.patch # gmake FREEBSD=yes Makefile:92: .depend: No such file or directory cc -MM -I. p4.c k8.c mcelog.c dmi.c tsc.c core2.c bitfield.c intel.c nehalem.c dunnington.c tulsa.c config.c memutil.c msg.c eventloop.c leaky-bucket.c memdb.c server.c client.c cache.c rbtree.c memstream.c .depend.Xmv .depend.X .depend cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o mcelog.o mcelog.c mcelog.c: In function 'process_kvm': mcelog.c:1342: error: 'X_SNAPDATE' undeclared (first use in this function) mcelog.c:1342: error: (Each undeclared identifier is reported only once mcelog.c:1342: error: for each function it appears in.) mcelog.c:1342: error: 'snapdate' undeclared (first use in this function) gmake: *** [mcelog.o] Error 1 please help me -- Vladimir Laskov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
problem with build mcelog
Hello. i am trying build mcelog FreeBSD 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14 04:15:56 UTC 2011 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 # fetch http://ftp2.pl.freebsd.org/pub/FreeBSD/distfiles/mcelog-1.0pre2.tar.gz # tar -xf mcelog-1.0pre2.tar.gz # cd mcelog-1.0pre2 # fetch http://people.freebsd.org/~jhb/mcelog/mcelog.patch # fetch http://people.freebsd.org/~jhb/mcelog/memstream.c # patch mcelog.patch # gmake FREEBSD=yes Makefile:92: .depend: No such file or directory cc -MM -I. p4.c k8.c mcelog.c dmi.c tsc.c core2.c bitfield.c intel.c nehalem.c dunnington.c tulsa.c config.c memutil.c msg.c eventloop.c leaky-bucket.c memdb.c server.c client.c cache.c rbtree.c memstream.c .depend.X mv .depend.X .depend cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o mcelog.o mcelog.c mcelog.c: In function 'process_kvm': mcelog.c:1342: error: 'X_SNAPDATE' undeclared (first use in this function) mcelog.c:1342: error: (Each undeclared identifier is reported only once mcelog.c:1342: error: for each function it appears in.) mcelog.c:1342: error: 'snapdate' undeclared (first use in this function) gmake: *** [mcelog.o] Error 1 please help me -- Vladimir Laskov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: linux PF_PACKET compatibility
On 2/11/11 1:36 AM, Da Rock wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) nothing in that page needs to talk to the network interface directly... what do you think does? FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
Alexander Leidinger alexan...@leidinger.net writes: Hi, during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. [...] Index: kern/kern_dtrace.c [...] +FEATURE(kdtrace_hooks, +Kernel DTrace hooks which are required to load DTrace kernel modules); + [...] Index: kern/kern_lockstat.c [...] +FEATURE(kdtrace_hooks, Kernel DTRACE hooks); Why description differs? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: linux PF_PACKET compatibility
On 2/11/11 5:40 AM, Da Rock wrote: On 02/11/11 19:54, Vlad Galu wrote: On Fri, Feb 11, 2011 at 11:36 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au mailto:freebsd-hack...@herveybayaustralia.com.au wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) I suppose you could just use mpd :) I could, I guess. But where's the fun in that? :) Seriously, though, mpd didn't quite cut it (I thought) for me. I need a l2tp vpn server with the capability to handle multiple clients with only one interface. The server is behind a firewall, and I'm trying for a walled garden variety I guess. So far my research has brought me here, but I'm open to suggestions. why do you think you need only one interface? One other that has my attention is l2tpd (in ports). I want radius auth, so IF I can use pppd in base and radius (which as I understand- so far anyway- it needs), and only uses a single interface, then maybe. pppd in base will I think give you multiple interfaces.. I'm still hunting and playing- learning on the fly. From what I read mpd uses an ng interface for every single client. L2tpns doesn't, and from what I've read so far neither does l2tpd (I was actually looking at another fork of that xl2tpd). I could use some advice from someone with experience with this, but my feelers on -questions didn't get much response. I may try on -net if this fails... again, whats' with the single interface? Aside from that I also wanted to get a bit more of a hands on feel for the FreeBSD core. I can't sit on the sidelines yelling at the players any more :) I'm not much for spectator sport either... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
On Fri, 2011-02-11 at 08:56 +0100, Damien Fleuriot wrote: Hi Devin, Thanks for sharing your work. The list strips non-text attachments so there isn't much to see at the moment though... Thanks Damien. Here's a link to the pic I posted online in-tandem with the post to the list(s). http://www.twitpic.com/3yhye7 -- Devin --- Fleuriot Damien On 11 Feb 2011, at 04:53, Devin Teske dte...@vicor.com wrote: Hi All, I'd like to announce the release of a new script. A script that I've developed for our field engineers that I'd like to share with the rest of the world. http://druidbsd.sourceforge.net/download/host-setup.txt host-setup(1) is a dialog(1)-based utility (written in sh(1)) designed to make configuring FreeBSD more efficient. We have this script configured to be run as root's initial login immediately after first-boot. The field engineer uses our custom installer to install RELENG_8, and after the machine presents a login prompt, they login with the pre-configured root password. After which they are presented with this dialog (image attached: host-setup.pub.png). The dialogs should all be intuitive, and I hope that you like my work. I've worked very hard to make this utility smooth, robust, fault-tolerant and even enjoyable to use. Not only that, but it helps prevents mistakes that could arise in doing these steps by-hand (like forgetting to unmount active NFS-mounts before executing route flush). Please give it a try and let me know what you think. -- Devin P.S. This is not a trivial script. ``More nuclear reactor than bike shed'' ^_^ P.P.S. Should be backward compatible to RELENG_4. P.P.S. I know the screenshot says host-setup.pub -- that's only because our in-house-only version has more functionality than the one I'm releasing to the general public today (no functionality that anyone in the public audience would ever care about though). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
On 11.02.2011 14:54, Alexander Leidinger wrote: As a 3rd point (attention bikeshed ahead), having everything as a FEATURE would give an uniform way of listing what is available or not (with the benefit to administratively hide parts of it). Needless to say that this would reduce the amount of knowledge and code to determine if something is available (as a person who works in a production environement with mixed knowledge levels of the people and who has to analyse problems which are sometimes caused by lack of knowledge of the people which implemented something, I welcome everything which lowers the learning curve and complexity). When I was beginning this GSoC work, I primarily thought about unifying the way to determine if particular feature exists in the kernel. Of course there should be at least one way to check if the feature is available or not (by definition: if I may use some functionality, than feature is present, otherwise... Oh, no, may be I have no permissions to use it? or something is terribly wrong with system confuguration? Or?...), but it is better to have a sort of unified way to get this information without looking for files in /dev, parsing `kldstat -v`, etc. -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab...@jabber.ru signature.asc Description: OpenPGP digital signature
Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
On 11.02.2011 17:38, Anonymous wrote: Alexander Leidinger alexan...@leidinger.net writes: Hi, during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. [...] Index: kern/kern_dtrace.c [...] +FEATURE(kdtrace_hooks, +Kernel DTrace hooks which are required to load DTrace kernel modules); + [...] Index: kern/kern_lockstat.c [...] +FEATURE(kdtrace_hooks, Kernel DTRACE hooks); Why description differs? !DSPAM:4d556bc9311932017213797! It was a mistake on my side, I've already removed duplicate definition in Perforce. Thank you for pointing this out though! -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab...@jabber.ru signature.asc Description: OpenPGP digital signature
Re: [RELEASE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
On Sat, 2011-02-12 at 02:30 +1100, Ian Smith wrote:
In freebsd-questions Digest, Vol 349, Issue 8, Message: 15
On Thu, 10 Feb 2011 19:53:53 -0800 Devin Teske dte...@vicor.com wrote:
Hi All,
I'd like to announce the release of a new script. A script that I've
developed for our field engineers that I'd like to share with the rest
of the world.
http://druidbsd.sourceforge.net/download/host-setup.txt
host-setup(1) is a dialog(1)-based utility (written in sh(1)) designed
to make configuring FreeBSD more efficient.
Nice, if only as great bedtime reading so far; I've already learned some
new techniques.
I'm particularly proud of this little diddy (see lines 1600-1607 of
host-setup; rewritten to be a functional example program that takes a
number like 26 and produces 255.255.255.192):
#!/bin/sh
blen2netmask() {
local nbits=$1 netmask= n=0
while [ $n -lt 4 ]; do
netmask=$netmask${netmask:+.}$((
(65280 ($nbits - 8 * $n) 255)
* ((8*$n) $nbits $nbits = (8*($n+1)))
+ 255 * ($nbits (8*($n+1)))
))
n=$(( $n + 1 ))
done
echo $netmask
}
blen2netmask $@
I wrote _several_ other implementations and above is the one that I
finally settled on as being the most elegant.
I was after a solution that (a) didn't use anything but built-in
internals of sh(1), and (b) got the job done as fast as computationally
possible.
$ time blen2netmask 26
255.255.255.192
real0m0.004s
user0m0.001s
sys 0m0.004s
That's pretty fast, I'd say ^_^ (faster than the other implementations
-- especially considering that it doesn't have to fork anything).
--
Devin
P.S. Maybe I ought to expand it to IPv6 considering that the IPv4
address space has [reportedly] finally ran out (is that true?).
I expect to steal lots of it wholesale (acknowledged :)
cheers, Ian
___
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
memstick.img is bloated with 7% 2K blocks of nulls
memstick.img wastes 7% with 2K blocks of nulls. shown by: 8f -b 0 -n 2048 -l -f Fr* http://berklix.com/~jhs/src/bsd/jhs/bin/public/8f/ 8f.c 8f.1 FreeBSD-8.1-RELEASE-amd64-bootonly.iso:543 FreeBSD-8.1-RELEASE-amd64-disc1.iso: 543 FreeBSD-8.1-RELEASE-amd64-dvd1.iso: 1125 FreeBSD-8.1-RELEASE-amd64-livefs.iso: 1109 FreeBSD-8.1-RELEASE-amd64-memstick.img: 38722 FreeBSD-8.1-RELEASE-i386-bootonly.iso: 511 FreeBSD-8.1-RELEASE-i386-disc1.iso:511 FreeBSD-8.1-RELEASE-i386-dvd1.iso: 865 FreeBSD-8.1-RELEASE-i386-dvd1.iso: 893 FreeBSD-8.1-RELEASE-i386-livefs.iso: 850 FreeBSD-8.1-RELEASE-i386-memstick.img: 34066 FreeBSD-8.2-RC3-amd64-bootonly.iso:594 FreeBSD-8.2-RC3-amd64-disc1.iso: 594 FreeBSD-8.2-RC3-amd64-dvd1.iso: 1167 FreeBSD-8.2-RC3-amd64-livefs.iso: 1166 FreeBSD-8.2-RC3-amd64-memstick.img: 39216 FreeBSD-8.2-RC3-i386-bootonly.iso: 565 FreeBSD-8.2-RC3-i386-disc1.iso:565 FreeBSD-8.2-RC3-i386-dvd1.iso: 906 FreeBSD-8.2-RC3-i386-livefs.iso: 905 FreeBSD-8.2-RC3-i386-memstick.img: 34521 It's not just one big block of trailing nulls. od -c FreeBSD-8.2-RC3-i386-memstick.img tmp.od ; tail tmp.od 7114017760@ 244 377 344 Q \b * 325 \t 333 y ` ' \n W 711402 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 711405 05 - 02 = 03 = 0x3000 = 12288 It's a lot of bursts of null blocks, seen by either: grep -n '^*' tmp.od 8f -f -c -b 0 -n 2048 FreeBSD-8.2-RC3-i386-memstick.img The CD DVD images are not nearly so wasteful, see above. As near 1G ( 959467520 FreeBSD-8.2-RC3-i386-memstick.img ) it will soon not fit on 1G sticks. If its not easy for someone to find trim, xz compression would at least save 27% of transmission bandwidth, ( dc 702447528 100 * 959467520 / p 73 ) a much higher % than DVD that also uses compression. PS I sent this to hackers@ rather than re@ as I imagine re@ are busy with more urgent matters at present :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
On Fri, 11 Feb 2011 20:09:30 +0100 Julian H. Stacey j...@berklix.com wrote: memstick.img wastes 7% with 2K blocks of nulls. Could this be due to using UFS1 instead of UFS2? On a related note, at some point the release scripts should be updated to use gpart instead of fdisk/bsdlabel. -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: problem with build mcelog
On Friday, February 11, 2011 7:48:39 am venom wrote: Hello. i am trying build mcelog FreeBSD 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14 04:15:56 UTC 2011 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 # fetch http://ftp2.pl.freebsd.org/pub/FreeBSD/distfiles/mcelog-1.0pre2.tar.gz # tar -xf mcelog-1.0pre2.tar.gz # cd mcelog-1.0pre2 # fetch http://people.freebsd.org/~jhb/mcelog/mcelog.patch # fetch http://people.freebsd.org/~jhb/mcelog/memstream.c Oops, I just updated mcelog.patch and it should work fine now. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
Nice Script! I intend to steal parts of it for my own use. P.S. Maybe I ought to expand it to IPv6 considering that the IPv4 address space has [reportedly] finally ran out (is that true?). All the available IPs were allocated to the RIRs. AFIK the RIRs have not had to deny anyone for insufficiency yet - but it will happen soon. -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
reverse of getchar() read() open() fopen() ?
Hi hackers@, Do we have C libraries with reverse of getchar() [ maybe read() ] fopen() [ maybe open() ] etc, to read from end of file toward beginning ? I dont see anything in the See Also sections. I'm not looking to write, just read. I'm looking for something that returns last char in file as first etc, I'm not interested in wchars etc, I could write some C functions, with seek etc probably will, if none exist, but no point if they already exist ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: reverse of getchar() read() open() fopen() ?
I've never seen any such thing, but I've done similar things a lot. I'd say malloc/read the whole file in and use a decrementing pointer to return the previous character. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On Behalf Of Julian H. Stacey [j...@berklix.com] Sent: Friday, February 11, 2011 4:32 PM To: hack...@freebsd.org Subject: reverse of getchar() read() open() fopen() ? Hi hackers@, Do we have C libraries with reverse of getchar() [ maybe read() ] fopen() [ maybe open() ] etc, to read from end of file toward beginning ? I dont see anything in the See Also sections. I'm not looking to write, just read. I'm looking for something that returns last char in file as first etc, I'm not interested in wchars etc, I could write some C functions, with seek etc probably will, if none exist, but no point if they already exist ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: reverse of getchar() read() open() fopen() ?
In the last episode (Feb 11), Julian H. Stacey said: Hi hackers@, Do we have C libraries with reverse of getchar() [ maybe read() ] fopen() [ maybe open() ] etc, to read from end of file toward beginning ? I dont see anything in the See Also sections. I'm not looking to write, just read. I'm looking for something that returns last char in file as first etc, I'm not interested in wchars etc, I could write some C functions, with seek etc probably will, if none exist, but no point if they already exist ? tail -r does this on a line-by-line basis. Tail does it for regular files by mmaping and then reading backwards, but you could also read the block of data at (filesize MOD buffersize) and return its bytes in reverse order, then seek back buffersize bytes, read that block and print it reversed, etc. You might even be able to write functions that could be passed to funopen(). Then you'd have a regular FILE* that you could call with regular stdio functions. Getting the buffering right for good performance might get tricky, though. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: reverse of getchar() read() open() fopen() ?
On Fri, 2011-02-11 at 22:32 +0100, Julian H. Stacey wrote: Hi hackers@, Do we have C libraries with reverse of getchar() [ maybe read() ] fopen() [ maybe open() ] etc, to read from end of file toward beginning ? `tail -r' will spit out lines of a file in reverse-order. Maybe the source to tail(1) can offer some insights: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/tail/ -- Devin P.S. Sorry for the non-answer. I dont see anything in the See Also sections. I'm not looking to write, just read. I'm looking for something that returns last char in file as first etc, I'm not interested in wchars etc, I could write some C functions, with seek etc probably will, if none exist, but no point if they already exist ? Cheers, Julian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: reverse of getchar() read() open() fopen() ?
Hi hackers@, Do we have C libraries with reverse of getchar() [ maybe read() ] fopen() [ maybe open() ] etc, to read from end of file toward beginning ? I dont see anything in the See Also sections. I'm not looking to write, just read. I'm looking for something that returns last char in file as first etc, I'm not interested in wchars etc, I could write some C functions, with seek etc probably will, if none exist, but no point if they already exist ? PS I'm not looking for a program that reverses chars in lines ( eg like my http://berklix.com/~jhs/src/bsd/jhs/bin/local/rev/ ), instead I'm wondering if we have functions that read binary backwards, \0 \n not special. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: reverse of getchar() read() open() fopen() ?
On Fri, Feb 11, 2011 at 10:32:46PM +0100, Julian H. Stacey wrote: Hi hackers@, Do we have C libraries with reverse of getchar() [ maybe read() ] fopen() [ maybe open() ] etc, to read from end of file toward beginning ? I dont see anything in the See Also sections. I'm not looking to write, just read. I'm looking for something that returns last char in file as first etc, I'm not interested in wchars etc, I could write some C functions, with seek etc probably will, if none exist, but no point if they already exist ? Use lseek() to position yourself, iterate over the file, copying into a small buffer, then iterate over your buffer in reverse? Maybe I misunderstood you... Cheers, Julian -- Brian Reichert reich...@numachi.com 55 Crystal Ave. #286 Derry NH 03038-1725 USA BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
problem with build mcelog
Hello. i am trying build mcelog # fetch http://ftp2.pl.freebsd.org/pub/FreeBSD/distfiles/mcelog-1.0pre2.tar.gz # tar -xf mcelog-1.0pre2.tar.gz # cd mcelog-1.0pre2 # fetch http://people.freebsd.org/~jhb/mcelog/mcelog.patch # fetch http://people.freebsd.org/~jhb/mcelog/memstream.c # patch mcelog.patch # gmake FREEBSD=yes Makefile:92: .depend: No such file or directory cc -MM -I. p4.c k8.c mcelog.c dmi.c tsc.c core2.c bitfield.c intel.c nehalem.c dunnington.c tulsa.c config.c memutil.c msg.c eventloop.c leaky-bucket.c memdb.c server.c client.c cache.c rbtree.c memstream.c .depend.X mv .depend.X .depend cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o mcelog.o mcelog.c mcelog.c: In function 'process_kvm': mcelog.c:1342: error: 'X_SNAPDATE' undeclared (first use in this function) mcelog.c:1342: error: (Each undeclared identifier is reported only once mcelog.c:1342: error: for each function it appears in.) mcelog.c:1342: error: 'snapdate' undeclared (first use in this function) gmake: *** [mcelog.o] Error 1 please help me -- Vladimir Laskov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: linux PF_PACKET compatibility
On 02/12/11 02:37, Julian Elischer wrote: On 2/11/11 1:36 AM, Da Rock wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) nothing in that page needs to talk to the network interface directly... what do you think does? I'm afraid you have me a little stumped. The PF_PACKET family talks directly with the network driver sending data to and from the app. Unfortunately this software uses this family instead of pcap or bpf. So when built it errors. I guess if I am to use this app I will have to rewrite the way it uses the network stack. FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: linux PF_PACKET compatibility
On 02/12/11 02:48, Julian Elischer wrote: On 2/11/11 5:40 AM, Da Rock wrote: On 02/11/11 19:54, Vlad Galu wrote: On Fri, Feb 11, 2011 at 11:36 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au mailto:freebsd-hack...@herveybayaustralia.com.au wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) I suppose you could just use mpd :) I could, I guess. But where's the fun in that? :) Seriously, though, mpd didn't quite cut it (I thought) for me. I need a l2tp vpn server with the capability to handle multiple clients with only one interface. The server is behind a firewall, and I'm trying for a walled garden variety I guess. So far my research has brought me here, but I'm open to suggestions. why do you think you need only one interface? One other that has my attention is l2tpd (in ports). I want radius auth, so IF I can use pppd in base and radius (which as I understand- so far anyway- it needs), and only uses a single interface, then maybe. pppd in base will I think give you multiple interfaces.. I'm still hunting and playing- learning on the fly. From what I read mpd uses an ng interface for every single client. L2tpns doesn't, and from what I've read so far neither does l2tpd (I was actually looking at another fork of that xl2tpd). I could use some advice from someone with experience with this, but my feelers on -questions didn't get much response. I may try on -net if this fails... again, whats' with the single interface? To be honest I don't know. But from what I've read up on it so far (including mpd - use and ng interface) I will have an net interface for every client. Apparently l2tpns doesn't do that, and one of the arguments for its use is that feature. If one has say 100 clients, each of those needs to be managed- 1 sounds better to me :) I am only working on theory here so far though, so please let me know if I'm on the wrong track. Cheers Aside from that I also wanted to get a bit more of a hands on feel for the FreeBSD core. I can't sit on the sidelines yelling at the players any more :) I'm not much for spectator sport either... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: reverse of getchar() read() open() fopen() ?
Andrew Duane wrote: I've never seen any such thing, but I've done similar things a lot. I'd say malloc/read the whole file in and use a decrementing pointer to return the previous character. Thanks, but I'll need a loop too, as malloc(filesize()) would be too big, as I omitted to say I'll be running it from find, reading all files on system, including DVD images @ 4.7G. Some of my machines dont have that much swap, let alone RAM :-) Aside: I was doing inefficient things here with getchar() (while searching forward, for a one off run, (CPU cycles were cheaper than brain cycles, so it was easier to hack a pre-existing prog that used getchar() ). I was doing a search for (trailing) nulls blocks, from BSD tar silently zeroing data from bad media, per http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034254.html http://www.freebsd.org/cgi/query-pr.cgi?pr=154407 http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/tar/ But my search logs from find with http://berklix.com/~jhs/src/bsd/jhs/bin/public/8f were too big, so I'll reduce by searching backward only indexing on trailing nulls. Dan Nelson wrote: You might even be able to write functions that could be passed to funopen(). Then you'd have a regular FILE* that you could call with regular stdio functions. Getting the buffering right for good performance might get tricky, though. Thanks, I didnt know funopen, I'll read it again tomorrow morning :-) Thanks to Devin Teske re src/usr.bin/tail/, sorry in my first post I forgot to say binary. Brian Reichert wrote: Use lseek() to position yourself, iterate over the file, copying into a small buffer, then iterate over your buffer in reverse? Yes, thanks, better for efficiency, being lazy I had first wondered if there was some fopen_starting_from_tail() getchar_starting_from_tail() I could just call for aone off run :-) Thanks all. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
On Fri, 11 Feb 2011, Alexander Leidinger wrote: during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. Here is the list of affected files (for those impatient ones which do not want to look at the attached patch before noticing that they are not interested to look at it): The additions for security/audit and security/mac both seem reasonable; I've been meaning to add them myself for quite a bit. There's then some code in libc that can learn to use this as well, at least for MAC. The one comment I'd make is that the MAC case should indicate that The MAC Framework is supported, rather than mandatory access controls being present -- the presence of the framework doesn't imply the presence of mandatory access control policies. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
Bruce Cran wrote:
On Fri, 11 Feb 2011 20:09:30 +0100
Julian H. Stacey j...@berklix.com wrote:
memstick.img wastes 7% with 2K blocks of nulls.
Could this be due to using UFS1 instead of UFS2?
Don't know, Looking:
8.1 /usr/src/release/scripts/make-memstick.sh
man makefs
-t fs-type ... The following file system
types are supported:
ffs BSD fast file system (default).
FFS-specific options
version UFS version. 1 for FFS (default), 2 for UFS2
/usr/src/release/Makefile --
scripts/doFS.sh:
newfs -i ${FSINODE} -o space -m 0 /dev/r${VNDEVICE}c
...
newfs -O1 -b 4096 -f 512 -i ${FSINODE} -o space -m 0 /dev/${MDDEVICE}
man newfs:
-O filesystem-type
Use 1 to specify that a UFS1 format file system be built; use 2
to specify that a UFS2 format file system be built. The default
format is UFS2.
If anyone fancies looking deeper, please do :-)
Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Mail plain text; Not quoted-printable, Not HTML, Not base 64.
Reply below text sections not at top, to avoid breaking cumulative context.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
On Fri, 11 Feb 2011, Ilya Bakulin wrote: When I was beginning this GSoC work, I primarily thought about unifying the way to determine if particular feature exists in the kernel. Of course there should be at least one way to check if the feature is available or not (by definition: if I may use some functionality, than feature is present, otherwise... Oh, no, may be I have no permissions to use it? or something is terribly wrong with system confuguration? Or?...), but it is better to have a sort of unified way to get this information without looking for files in /dev, parsing `kldstat -v`, etc. One of the nice things about this is that when a conditionally compiled feature introduces a new system call, there can be forward (rather than backward) compatibility benefits. If login(1) had checked for the Audit feature before trying audit system calls when we introduced it in 6.x, it would have avoided a few people shooting their feet off in the (officially unsupported) case where following a kernel and userspace roll-forward, a kernel roll-back was required to restore stability. While we don't support it (you shouldn't run a new userspace with an old kernel), the failure mode would have been improved. More abstractly: for a feature like MAC, testing for the presence of the framework is functionally fairly different from exercise the feature, as most instances of exercising it work only based on modules loaded by the framework, which is a different goal. Right now, libc offers a mac_present API, which back-ends into manually testing a system call. I'd rather it backended into a common feature test framework. In many cases, it is of course desirable to test for a feature by using it -- a much more pragmatic approach, and generally one preferred in the world of autoconf, etc... Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: memstick.img is bloated with 7% 2K blocks of nulls
On Sat, 12 Feb 2011 01:54:58 +0100 Julian H. Stacey j...@berklix.com wrote: -O filesystem-type Use 1 to specify that a UFS1 format file system be built; use 2 to specify that a UFS2 format file system be built. The default format is UFS2. If anyone fancies looking deeper, please do :-) I checked with dumpfs that memstick.img is UFS1. Also, mounting /dev/md0 confuses the kernel into ultimately panic'ing, since /dev/md0a is the proper slice. For the mfsroot.gz file from the CD ISOs: # mdconfig -a -f mfsroot md0 # mount /dev/md0a /mnt # ls /mnt ls: /mnt: Bad file descriptor # cd /mnt cd: /mnt: Not a directory # vim /mnt panic: ffs_read: type 0 kdb_enter() panic() ffs_read() vn_read dofileread() kern_readv() read() syscallenter() syscall() Xfast_syscall() -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: linux PF_PACKET compatibility
On 2/11/11 4:08 PM, Da Rock wrote: On 02/12/11 02:48, Julian Elischer wrote: On 2/11/11 5:40 AM, Da Rock wrote: On 02/11/11 19:54, Vlad Galu wrote: On Fri, Feb 11, 2011 at 11:36 AM, Da Rock freebsd-hack...@herveybayaustralia.com.au mailto:freebsd-hack...@herveybayaustralia.com.au wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) I suppose you could just use mpd :) I could, I guess. But where's the fun in that? :) Seriously, though, mpd didn't quite cut it (I thought) for me. I need a l2tp vpn server with the capability to handle multiple clients with only one interface. The server is behind a firewall, and I'm trying for a walled garden variety I guess. So far my research has brought me here, but I'm open to suggestions. why do you think you need only one interface? One other that has my attention is l2tpd (in ports). I want radius auth, so IF I can use pppd in base and radius (which as I understand- so far anyway- it needs), and only uses a single interface, then maybe. pppd in base will I think give you multiple interfaces.. I'm still hunting and playing- learning on the fly. From what I read mpd uses an ng interface for every single client. L2tpns doesn't, and from what I've read so far neither does l2tpd (I was actually looking at another fork of that xl2tpd). I could use some advice from someone with experience with this, but my feelers on -questions didn't get much response. I may try on -net if this fails... again, whats' with the single interface? To be honest I don't know. But from what I've read up on it so far (including mpd - use and ng interface) I will have an net interface for every client. Apparently l2tpns doesn't do that, and one of the arguments for its use is that feature. If one has say 100 clients, each of those needs to be managed- 1 sounds better to me :) I am only working on theory here so far though, so please let me know if I'm on the wrong track. if you have multiple interfaces you can set differnt mtus for them etc. and routing is more straight forward. you can do tcpdump on a particular interface or filter on just one interface. there have been people with 100 interfaces.. who didn't seem to have any problems. there are advantages and disadvantages. Cheers Aside from that I also wanted to get a bit more of a hands on feel for the FreeBSD core. I can't sit on the sidelines yelling at the players any more :) I'm not much for spectator sport either... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To
Re: [RELEASE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
On 2/11/11 4:53 AM, Devin Teske wrote: Hi All, I'd like to announce the release of a new script. A script that I've developed for our field engineers that I'd like to share with the rest of the world. http://druidbsd.sourceforge.net/download/host-setup.txt host-setup(1) is a dialog(1)-based utility (written in sh(1)) designed to make configuring FreeBSD more efficient. We have this script configured to be run as root's initial login immediately after first-boot. The field engineer uses our custom installer to install RELENG_8, and after the machine presents a login prompt, they login with the pre-configured root password. After which they are presented with this dialog (image attached: host-setup.pub.png). The dialogs should all be intuitive, and I hope that you like my work. I've worked very hard to make this utility smooth, robust, fault-tolerant and even enjoyable to use. Not only that, but it helps prevents mistakes that could arise in doing these steps by-hand (like forgetting to unmount active NFS-mounts before executing route flush). Please give it a try and let me know what you think. -- Devin P.S. This is not a trivial script. ``More nuclear reactor than bike shed'' ^_^ P.P.S. Should be backward compatible to RELENG_4. P.P.S. I know the screenshot says host-setup.pub -- that's only because our in-house-only version has more functionality than the one I'm releasing to the general public today (no functionality that anyone in the public audience would ever care about though). Hi Devin, Thanks for sharing, but I'm afraid the list automagically strips away non-text attachments, you'll have to upload your screenshots somewhere :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [maybe spam] Re: linux PF_PACKET compatibility
On 2/11/11 4:03 PM, Da Rock wrote: On 02/12/11 02:37, Julian Elischer wrote: On 2/11/11 1:36 AM, Da Rock wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) nothing in that page needs to talk to the network interface directly... what do you think does? I'm afraid you have me a little stumped. The PF_PACKET family talks directly with the network driver sending data to and from the app. Unfortunately this software uses this family instead of pcap or bpf. So when built it errors. I guess if I am to use this app I will have to rewrite the way it uses the network stack. l2tp runs over UDP packets (port 1701 (like the starship enterprise)) I have no idea why they want raw packets. talk to the writer of the web page you indicated.. maybe he can help.. FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use in this function) arp.c:59: error: (Each undeclared identifier is reported only once arp.c:59: error: for each function it appears in.) arp.c:62: error: 'AF_PACKET' undeclared (first use in this function) arp.c:34: warning: unused variable 'sll' gmake: *** [arp.o] Error 1 I posted this over at -questions@ but it was suggested to try here instead (or -net@). I figured this would be the best place to start... :) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
ixgbe DMA question
I have a host machine with 2 ixgbe NICs. I am trying to pass the frames from one NIC to the other with the lowest possible overhead to the host (high speed bridge). I am wondering if I can do a rx-ring to tx-ring DMA copy without creating a mbuf on the host. Is that possible? What are the risks? Thanks, -santosh ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
problem with build mcelog
Hello. i am trying build mcelog FreeBSD 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14 04:15:56 UTC 2011 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 # fetch http://ftp2.pl.freebsd.org/pub/FreeBSD/distfiles/mcelog-1.0pre2.tar.gz # tar -xf mcelog-1.0pre2.tar.gz # cd mcelog-1.0pre2 # fetch http://people.freebsd.org/~jhb/mcelog/mcelog.patch # fetch http://people.freebsd.org/~jhb/mcelog/memstream.c # patch mcelog.patch # gmake FREEBSD=yes Makefile:92: .depend: No such file or directory cc -MM -I. p4.c k8.c mcelog.c dmi.c tsc.c core2.c bitfield.c intel.c nehalem.c dunnington.c tulsa.c config.c memutil.c msg.c eventloop.c leaky-bucket.c memdb.c server.c client.c cache.c rbtree.c memstream.c .depend.X mv .depend.X .depend cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o mcelog.o mcelog.c mcelog.c: In function 'process_kvm': mcelog.c:1342: error: 'X_SNAPDATE' undeclared (first use in this function) mcelog.c:1342: error: (Each undeclared identifier is reported only once mcelog.c:1342: error: for each function it appears in.) mcelog.c:1342: error: 'snapdate' undeclared (first use in this function) gmake: *** [mcelog.o] Error 1 please help me -- Vladimir Laskov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [maybe spam] Re: linux PF_PACKET compatibility
On 02/12/11 11:19, Julian Elischer wrote: On 2/11/11 4:03 PM, Da Rock wrote: On 02/12/11 02:37, Julian Elischer wrote: On 2/11/11 1:36 AM, Da Rock wrote: On 02/11/11 18:17, Julian Elischer wrote: On 2/10/11 11:22 PM, Da Rock wrote: In recent versions of the Linux kernel (post-2.0 releases) a new protocol family has been introduced, named PF_PACKET. This family allows an application to send and receive packets dealing directly with the network card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any packet sent through the socket will be directly passed to the Ethernet interface, and any packet received through the interface will be directly passed to the application. I've been chasing the answer to a FreeBSD version of this (approx. anyway), but I needed to find out what exactly PF_PACKET was first. Finally found this answer here: http://www.linuxjournal.com/article/4659 I looked up man socket and I can see possibilities (in my mind anyway), but I thought I'd be best to check if the gurus here might have a better idea. My reason for this is I'm attempting to build l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm chasing the errors which appear to be linuxisms mostly. So in man socket simply looking at the list of protocol families I'd say network driver level would be similar to PF_LINK link layer interface? Is there another man page I should be looking at as well? We don't have an exact equivalent.. but we have ways of doing the same thing. one way that is suggested is to use pcap and bpf which I am pretty certain has been enhanced to allow sending as well as receiving. you can also hook directly to the interface using netgraph(4) there are other ways too but those are the two that came to mind immediately. So I'm going to have to rewrite that interface entirely? Bugger! I just can't fathom how this howto could even exist for l2tpns on FreeBSD if it isn't even close to buildable... weird! http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html Thanks guys. I'll probably come back with more problems as I slowly crack this one... :) nothing in that page needs to talk to the network interface directly... what do you think does? I'm afraid you have me a little stumped. The PF_PACKET family talks directly with the network driver sending data to and from the app. Unfortunately this software uses this family instead of pcap or bpf. So when built it errors. I guess if I am to use this app I will have to rewrite the way it uses the network stack. l2tp runs over UDP packets (port 1701 (like the starship enterprise)) I have no idea why they want raw packets. Neither do I. talk to the writer of the web page you indicated.. maybe he can help.. I did. No response so far... It was for 7.3, but I can't see the difference. (I'll merge the 2 threads of this to make it easier and less consuming) again, whats' with the single interface? To be honest I don't know. But from what I've read up on it so far (including mpd - use and ng interface) I will have an net interface for every client. Apparently l2tpns doesn't do that, and one of the arguments for its use is that feature. If one has say 100 clients, each of those needs to be managed- 1 sounds better to me :) I am only working on theory here so far though, so please let me know if I'm on the wrong track. if you have multiple interfaces you can set differnt mtus for them etc. and routing is more straight forward. you can do tcpdump on a particular interface or filter on just one interface. there have been people with 100 interfaces.. who didn't seem to have any problems. there are advantages and disadvantages. I'd say you're right. But if you have all those interfaces (and this what my first thought was when I started this) then it requires more holes in the firewall- right? So for every ng interface I'd need to accept 1701, which gets messy in PF because I'd have to dictate where to rdr every incoming 1701. OTOH, if I have just a tun device for every 1701 to connect to then I only have to rdr all 1701 to the l2tp server. Routing can be done just on that server (mostly to reroute back out again) either through ppp static routing or otherwise. At least this is my impression so far. By all means let me know if I'm idiot with my head on backwards- I'm trying to get beyond theory before I start chatting on the -net list... :) FWIW my gmake output is this: gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I. -I/usr/include -I/usr/local/include -DLIBDIR='/lib/l2tpns' -DETCDIR='/etc/l2tpns' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL -DBGP -c -o arp.o arp.c arp.c: In function 'sendarp': arp.c:34: error: storage size of 'sll' isn't known arp.c:59: error: 'PF_PACKET' undeclared (first use
Re: [RELEASE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
On Fri, 11 Feb 2011, Eitan Adler wrote: Nice Script! I intend to steal parts of it for my own use. It's great when you can plunder without robbing anyone :) P.S. Maybe I ought to expand it to IPv6 considering that the IPv4 address space has [reportedly] finally ran out (is that true?). All the available IPs were allocated to the RIRs. AFIK the RIRs have not had to deny anyone for insufficiency yet - but it will happen soon. Yes Devin, best not leave it till August! For those wanting a near-obsessively detailed analysis of IPv4 depletion stats and predictions over many years, hard to go past Geoff Huston's: http://www.potaroo.net - blog http://www.potaroo.net/ispcol/2010-10/when.html - explanatory column Oct '10 http://www.potaroo.net/tools/ipv4/index.html - the modelling as of today cheers, Ian (Sorry, missed the cc to hackers@, adding questions@ back in the loop) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ixgbe DMA question
On Fri, 11 Feb 2011, Santosh Rao Gururajan wrote: I have a host machine with 2 ixgbe NICs. I am trying to pass the frames from one NIC to the other with the lowest possible overhead to the host (high speed bridge). I am wondering if I can do a rx-ring to tx-ring DMA copy without creating a mbuf on the host. Is that possible? What are the risks? The only real risk is the simple matter of programming, I think. There's no reason not to it except that it involves modifying device drivers, memory models, etc. If you do what you describe, and you decide you do want to pass some frames up the stack, you can always hook up mbufs and use the external storage free routine to return the memory to the ring. Jeff Roberson has been circulating some patches that eliminate the mbuf-cluster relationship in its current form, instead preferring variable size mbufs, and I can't help but wonder if with such a patch, that wouldn't be simpler than what you propose, offering many of the same performance benefits while making the device driver changes smaller and still allowing you to direct some packets up the stack if desired. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
