Re: GDB auto enter/detach patch
Nate Lawson writes:
I've put together a patch that enables a kernel on the target machine to
detect a GDB packet and automatically enter GDB mode. When the debugger
detaches, it also continues execution. This speeds up debugging,
especially when the target is in a remote location. The patch plus more
explanation is at:
http://www.root.org/~nate/freebsd/
Neat. A couple of comments:
1. I think a better abstraction of the GDB packet protocol would
be something like this:
struct gdb_parse {
int state; /* opaque state value */
u_int len;/* current packet length */
u_int maxlen; /* maximum packet length */
u_char data[0];/* packet data */
};
extern void gdb_parse_init(struct gdb_parse *p);
extern int gdb_parse_byte(struct gdb_parse *p);
That is, if you're doing the state machine, why not go ahead
and decode the packet data as well?
2. You need to handle the escape mechanism for packets containing
raw data.: '$', '#', and '~' are escaped with '~' characters
in case the the 'X' command is used.
3. I think GDB_AUTO_DETACH should be mandatory, i.e., the current
state of affairs is a bug IMHO.
4. Does FreeBSD use the 'O' command to send ordinary serial port output
when GDB mode is active? Haven't looked but this would be nice to
have if it's not already there.
5. Receipt of a '$' character should always reset the state, no?
(modulo the '~' escape mechanism mentioned above).
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Netgraph TCP/IP
Steve Tremblett writes: A while back someone was fishing for a project to take on and someone suggested a complete TCP/IP implementation in netgraph. I found the idea interesting and am considering taking a shot at it. My main goal in all this is to learn as much as possible and at this point I'm just reading. While this is a personal educational project, I figure I should propose it here and solicit comments/thoughts/suggestions on such a venture so that maybe the results might be usable by someone else. Are you intending to have this hook into the normal FreeBSD TCP/IP stack or be truly standalone? I read your question as the latter but others seem to read it as the former. If the latter, I'd suggest splitting it up into several netgraph nodes, eg.: | | | | | | ng_udpng_tcp \ / \ / ng_ip | | ng_arp | | | | ng_ether -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mpd for pptp - can't connect
[ moving discussion to freebsd-net ] Dan Langille writes: A while back, mpd was suggested as a pptp client. I've started looking at it. However, I'm having trouble getting it to connect. The office has a MS server and I'm trying to connect using mpd. FWIW, I can connect via pptp-client. The office IP is 1.2.3.4 My dual homed gateway has an internal address of 192.168.0.21 (ie. that's my default address for boxes on the home LAN). The office server has internal address of 10.0.0.18 I can connect using MS CHAP V2, MPPE 128, MPPC from my W2K box. Of note, I see this in the logs but don't know the significance: pptp0: CID 0xbc51 in SetLinkInfo not found That can be safely ignored. Just another harmless Windows bug. vpn: new -i ng1 vpn vpn set iface disable on-demand set iface addrs 192.168.0.21 10.0.1.18 set iface idle 0 set iface route 10.0.1.0/24 set pptp peer 1.2.3.4 set bundle disable multilink set bundle authname dan set bundle password secret set link yes acfcomp protocomp set link no pap set link enable chap set link accept chap set ipcp no vjcomp Try set link disable chap instead. The Windows box may be getting confused when you try to authenticate it. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Bad TCP checksum
Fred Souza writes: I'm experiencing something weird with my 4.6-RC box (compile of May 18). What happens is that for some hosts it just won't calculate the checksum properly, and thus my box is unable to start TCP connections to those hosts. Here's a piece of the output of tcpdump: 19:16:55.759657 me.50441 somehost.http: S [bad tcp cksum fffe!] 2079216431:2079216431(0) win 65535 mss 1452,nop,wscale 1,nop,nop, timestamp 797082 0 (DF) [tos 0x10] (ttl 96, id 41580, len 60) Additional info that might help: The default route goes through the tun0 interface, my ADSL service uses PPPoE and therefore I cannot think of any other way to work it out on FreeBSD. ppp(8) was compiled in the same day as the kernel, and I tried unloading firewalling and nothing different occured (at least apparently). NAT is disabled here. Sounds like it might be the delayed checksum code. What Ethernet device driver are you using? -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
splimp() during panic?
Hi, I'm trying to debug a mbuf corruption bug in the kernel. I've added an mbuf sanity check routine which calls panic() if anything is amiss with the mbuf free list, etc. This function runs at splimp() and if/when it calls panic() the cpl is still at splimp(). My question is: does this guarantee that the mbuf free lists, etc. will not be modified between the time panic() is called and the time a core file is generated? For example, if an incoming packet causes a networking interrupt after panic() has been called but before the core file is written, will that interrupt be blocked when it calls splimp()? I've been working under this assumption but it seems to not be valid, because I seem to be seeing panics for situations that are not true in the core file. If this is not a valid assumption, is there an easy way to 'freeze' the mbuf free lists long enough to generate the core file when an inconsistency is found (other than adding the obvious hack)? Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: splimp() during panic?
Bosko Milekic writes: My question is: does this guarantee that the mbuf free lists, etc. will not be modified between the time panic() is called and the time a core file is generated? For example, if an incoming packet causes a networking interrupt after panic() has been called but before the core file is written, will that interrupt be blocked when it calls splimp()? splimp() ensures that no driver handlers will be executed. Further, dumpsys() is called from panic() at splhigh() which would also mean that none of those potentially troublesome handlers will run. OK, good... I've been working under this assumption but it seems to not be valid, because I seem to be seeing panics for situations that are not true in the core file. Are you seeing invalid stuff from DDB but valid stuff from the core file? Because if so, that's REALLY WIERD. If you're just seeing two different but invalid things, then perhaps something is happening when Debugger() runs (is it possible that the cpl() is changed after or before a breakpoint()?). I'm not trying to use DDB for debugging.. just letting it panic and generate the core file and then using GDB to examine it. I got one panic that happened because mclfree was NULL (it was a bug in the debug code :-) but looking at mclfree in the core file with GDB showed it to be not NULL. So somehow some mbuf operation must have occurred in there somewhere that modified mclfree it seems. If this is not a valid assumption, is there an easy way to 'freeze' the mbuf free lists long enough to generate the core file when an inconsistency is found (other than adding the obvious hack)? To make doubly-sure, what you can do is just keep a variable 'foo' which you initialize to 0. Before any mbuf free list manipulations, place a 'if (foo == 0)' check. Atomically set foo to 1 before the panic. See if the inconsistency changes. If you're seeing garbage in Yep, I'll probably do that as well.. thanks. Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Anyone using pptp?
Thomas David Rivers writes: If I add enable MSChapV2 in /etc/ppp/ppp.conf - then our ppp client requires that the peer (the Microsoft VPN server) authenticate using MSChapV2. But, the Microsoft VPN peer refuses that (it's configured to not use MSChapV2. Don't you want something like allow MSChapV2 and disable MSChapV2 ? -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Anyone using pptp?
Thomas David Rivers writes: enable MSChapV2 in /etc/ppp/ppp.conf - then our ppp client requires that the peer (the Microsoft VPN server) authenticate using MSChapV2. But, the Microsoft VPN peer refuses that (it's configured to not use MSChapV2. Don't you want something like allow MSChapV2 and disable MSChapV2 ? Something like that... but - that's the default setting. With the default setting, it seems to pass through CHAP (0x80) Authentication. But - then, the MPPE encryption is not allowed - because MPPE compression requires MSChapV2 (0x81) Authentication... and, the VPN server doesn't authenticate that way. I notice there is a line in the ppp man page: For now, ppp can only get encryption keys from CHAP 81 authentication. But - the (Microsoft Win2000) VPN server I'm trying to talk do doesn't allow CHAP 81 authentication, but wants to use MPPE... In that case you need to use mpd I guess. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Anyone using pptp?
[ note: freebsd-hackers being removed from the cc: list ] Thomas David Rivers writes: mpd fails as well... with something very similar... it seems to send a CCP configuration request and simply gets no answer back from the Microsoft server. From the VPN log (you can see toward the bottom that both IPCP and CCP complain that parameter negotiation failed): Maybe the server is having trouble acquiring an IP address for you via DHCP? Sometimes this kind of trace results from the server 'freezing up' due to any random error condition such as no DHCP, network access denied, etc. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Dave Hayes writes: What does the _BP extension mean on the RELENG tags? Branch point. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vlan traffic over ipsec tunnel
Terry Lambert writes: Bridging doesn't work with the vlanX interface currently in FreeBSD. Why not? I believe you, I've just never used vlans and always assumed that they acted like normal Ethernet interfaces. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
kernel realloc() ?
For a project I'm working on, we need a kernel version of realloc().
Two questions:
#1 Does the patch below look correct?
#2 If so, is this something worth committing?
Thanks for any comments.
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
--- sys/malloc.h.orig Wed Nov 28 21:56:23 2001
+++ sys/malloc.hThu Nov 29 10:58:30 2001
@@ -176,6 +176,8 @@
void *malloc __P((unsigned long size, struct malloc_type *type, int flags));
void malloc_init __P((void *));
void malloc_uninit __P((void *));
+void *realloc __P((void *addr, unsigned long size,
+ struct malloc_type *type, int flags));
#endif /* _KERNEL */
#endif /* !_SYS_MALLOC_H_ */
--- kern/kern_malloc.c.orig Wed Nov 28 21:45:18 2001
+++ kern/kern_malloc.c Wed Nov 28 22:12:07 2001
@@ -404,6 +404,43 @@
}
/*
+ * realloc: change the size of a memory block
+ */
+void *
+realloc(addr, size, type, flags)
+ void *addr;
+ unsigned long size;
+ struct malloc_type *type;
+ int flags;
+{
+ struct kmemusage *kup;
+ long alloc;
+ void *mem;
+
+ /* Sanity checks */
+ if (type-ks_limit == 0)
+ panic(realloc with unknown type (%s), type-ks_shortdesc);
+ KASSERT(kmembase = (char *)addr (char *)addr kmemlimit,
+ (realloc: address %p out of range, (void *)addr));
+
+ /* Get size of original block; reuse if appropriate */
+ kup = btokup(addr);
+ alloc = 1 kup-ku_indx;
+ if (size = alloc
+(size = (alloc 1) || alloc == MINALLOCSIZE))
+ return (addr);
+
+ /* Allocate new block */
+ if ((mem = malloc(size, type, flags)) == NULL)
+ return (NULL);
+
+ /* Copy over contents */
+ bcopy(addr, mem, alloc);
+ free(addr, type);
+ return (mem);
+}
+
+/*
* Initialize the kernel memory allocator
*/
/* ARGSUSED*/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: netgraph one2many question
Milon Papezik writes: I would like to extend ng_one2many module to include automatic link failure datection, failover and FEC functionality. My question is: Are interface nodes able to send upstream notification that their state has changed or do I have to poll their status periodically as it is done in ng_fec module made kindly available by wpaul ? They don't now, but I think you could add this in a reasonably unoffensive way. What you would do is add a new function pointer to struct ifnet, say void (*if_report)(struct ifnet *, int status) or something. When a device driver detected link going up/down, it could call this function (if non-NULL). Then if_ethersubr() would set this function pointer to point to some function if_ether_report(). When if_ether_report() is called, if ng_ether was loaded, it would call into ng_ether() to generate a control message that would be passed to the node connected to the lower hook. Then, ng_one2many could be modified to understand this control message and do the right thing according to its configuration. Or, something like that. Polling might be a quicker and easier though less precise way to do it for starters. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: send/sendto/sendmsg and ECONNREFUSED
Richard Hodges writes: I just spent a good half hour trying to figure out a strange problem with a UDP socket. I connect()'ed the socket, and used send() to send small UDP packets to a server. Real basic stuff, right? Using tcpdump on the receiver, I could see that every other packet was sent successfully, the other half died in the sender. The send() call returned 61, ECONNREFUSED. This is not listed in the man pages, but a few minutes searching the web turned up the explanation - I had forgotten to start the UDP receiver... This may be a Well, duh! issue for some, but I think it might be appropriate to add a line for ECONNREFUSED in the man pages for send/sendto/sendmsg. It may be obvious, but is it _painfully_ obvious that the ICMP reply will trigger ECONNREFUSED on the next packet? Email me a man page patch and I'll review commit it. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to transfer data from netgraph node to user program?
Roman V. Palagin writes: When size of collected data about 10Kb, all works fine. But when I need to send 400Kb in reply - oops, ng_xxx_show_data() returns ENOBUFS (I think because ng_socket receive queue is full, nobody reads from socket). So, I don't understand how I can transfer large amount of data :-\ Any ideas? FreeBSD 4.x will not allow a context switch from within the kernel. Therefore, it is possible to overflow a socket if you keep adding data to it without leaving the kernel... because the user process never gets a chance to read the data. Maybe you can set a short timeout in your node after writing a certain amount of data, return, and then write some more when the timer goes off. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to transfer data from netgraph node to user program?
Roman V. Palagin writes: I've wrote netgraph node which collects some information from network. Now I want to transfer collected data into user program. I've NGM_XXX_STAT message which initiates data transfer and program which uses libnetgraph to communicate with node. When I send NGM_XXX_STAT message node must starts data transfer but I don't know exactly how much data should be transfered so I can't use synhronous reply. Also, NgSendMsg(..., NGM_XXX_STAT, ...) doesn't return until handler of NGM_XXX_STAT is finished, so I can't use ng_send_msg() in NGM_XXX_STAT handler - nobody will read sended messages and I finished up with No buffer space available. The question is: how I can initiate smth. like asynchronous reply (so I can get data via NgRecvMsg later in my prgram)? Or I'm going wrong way and should use another scheme for data transfer? Data size ranges from 10Kb to 500Kb. Whenever you're ready to send the reply, just create one and send it. You'll want the same 'token' value in the reply and you'll want to set the NGF_REPLY bit in the flags word to indicate it's a reply. For an exmple of doing this, see pppoe_send_event() in ng_pppoe.c (this is not a reply but shows how to create and send a message). -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Programming the WinBond W83781D
Torbjorn Kristoffersen writes: I'm porting a Linux module that reads system health information (such as voltages and temperatures) from a WinBond W83781D chip. What's the best way of extracting such info from the chip? In the Linux module it uses the regular inb(), outb(), set() etc. to read the raw data, and then making it look nice and dandy using a readable file in the proc filesystem. I'm not sure how to do this in FreeBSD.. Check out the "healthd" port which shows how to do it via /dev/io or /dev/smb0. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
Warner Losh writes: : OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who : *wants* that feature to sit down and code it. It won't happen otherwise. : : So, out of idle curiousity: If, somewhere down the road, I know the kernel : well enough to attempt such a thing, what would the interest level be in : merging such a feature? Assuming that it doesn't break anything, that it doesn't introduce a severe performance penalty and works, there would be interest. There are times that this is a desirable feature. This thread reminds me of what happened when I brought up the same issue a few years ago, arguing that the kernel shouldn't overcommit memory (i.e., the same thing, everybody though I was nuts :) For me it helps to understand people's underlying motivation. Here's mine... my perspective probably comes from using FreeBSD in the embedded world, which is very different from using FreeBSD in the rack-mounted server world. One important way to gain confidence that you're little box won't silently crash at the worst possible time for the customer is to be able to *prove* to yourself that it can't happen, given certain assumptions. Those assumptions usually include things like "the hardware is working properly" (e.g., no ECC errors) and "the compiler compiled my C code correctly". Given these basic assumptions, you go through and check that you've properly handled every possible case of input (malicious or otherwise) from the outside world. Part of the "proof" is verifying that you've checked all of your malloc(3) return values for NULL.. and assuming that if malloc(3) returns != NULL, then the memory is really there. Now, if malloc can return NULL and the memory *not* really be there, there is simply no way to prove that your code is not going to crash. This memory overcommit thing is the only case that I can think of where this happens, given the basic assumptions of correctly functioning hardware, etc. That is why it's especially annoying to (some) people. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: call for testers: port aggregation netgraph module
Bill Paul writes: This is a call for testers for a netgraph module that can be used to aggregate 2 or 4 ethernet interfaces into a single interface. Basically, it lets you do things like the following: You know, so far I've gotten close to a dozen replies to this e-mail, but none of contain the one thing I really wanted, namely test results. Look. I said this was a call for *testers*. Not kibitzers, not criticizers, not commenters, not lamers -- *testers*. I want you to try out the code and tell me if it works or not, and if not, describe the bugs so I can fix them. I don't want to hear anything else. If your e-mail concerns any other topic, it will be summarily ignored. Got it people? Good. Sorry.. I guess we all simultaneously forgot that you were the center of the universe. What's wrong with a little discussion? If you're not interested in it, that's fine, but can't the rest of us be? -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: call for testers: port aggregation netgraph module
Bill Paul writes: http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz This is a call for testers for a netgraph module that can be used to aggregate 2 or 4 ethernet interfaces into a single interface. Basically, it lets you do things like the following: # kldload ./ng_fec.ko # ngctl mkpeer fec dummy fec # ngctl msg fec0: add_iface '"dc0"' # ngctl msg fec0: add_iface '"dc1"' # ngctl msg fec0: add_iface '"dc2"' # ngctl msg fec0: add_iface '"dc3"' # ngctl msg fec0: set_mode_inet Bill, Just curious.. did you consider adding this functionality to the ng_one2many(4) node type? I suppose the ifmedia would have to be done more indirectly, eg., by adding a new control message supporting it to ng_ether(4). -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
new /etc/malloc.conf option
Here's an idea for a new /etc/malloc.conf option to help with
debugging... I'm interested in what other people think.
The option would have the effect of setting a "failure probability"
P between 0.0 and 1.0 such that any malloc()/realloc() operation would
fail with probability P.
Sometimes I've implemented this kind of thing manually to test code
robustness and it's been very helpful in catching obscure bugs.
You can't do this with a single letter, but maybe we could do something
like this using a number between 0..100:
$ ln -s F5AJ /etc/malloc.conf
Then in the malloc code read out the 'F5' at startup and set
failure_prob to 5%...
static u_int failure_prob; /* a number between 0 and 100 */
void *
malloc(size_t len)
{
u_int failure_index;
if (failure_prob != 0 (random() % 100) failure_prob) {
errno = ENOMEM;
return (NULL)
}
}
This would then give you a 1% failure probability.
By using random(), the exact failure can be reproduced by the application
by setting the same seed with srandom(). We might want to use a more
precise range, e.g., 0..100 instead of 0..100.
-Archie
______
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Divert Sockets Fragmentation revisited
Alwyn Goodloe writes: Guys still having problems with divert sockets and fragmentation. As I said in a previous post the divert operations and corresponding program work fine when the datagram sent have size MTU (1500) but when the datagram has size MTU and hence get fragmented the recfrom just waits never receiving anything. I am attaching the relevent code fragments below. tcpdump tells me that the packets arrive on the interface. Hence I know the fragments arrive. Now my ipfw commands are: ipfw add 6 divert 4422 udp from any to any 3322 in ipfw add 65000 allow ip from any to any I think the problem is that the first fragment is matching your rule, but not subsequent fragments (because the port number is only contained in the first fragment..) Now I thought that that maybe the divert being so specific was a problem so I tried flushing ipfw and using the command: ipfw add 6 divert 4422 ip from any to any thus diverting any ip packets and still nothing. That doesn't make sense.. Try adding the "log" keyword to your ipfw commands, or checking the stats with "ipfw show" so you can see exactly what's being diverted. Now according to the man page on divert: Incomming packets which get diverted are fully reassembled before delivery of any one fragment. Diversion of any one packet causes the entire packet to get diverted. I different fragments get diverted to different ports, then which port ultimately gets diverted is unpredictable. I was under the impression that the packets wern't reassemblembed before diversion. Am I wrong here? Yes... but all fragments must match. -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sf driver problem?
Has anyone had any luck in figuring out why the Adaptec ANA four-port Ethernet cards dramatically slow down the machine when all four ports are in use? http://www.freebsd.org/cgi/query-pr.cgi?pr=22624 (nevermind the video interrupt conflict theory, that doesn't seem to have anything to do with it) Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting default hostname to localhost
Warner Losh writes: : Unless there are some really good reasons : not to (which there may be), I'd like to commit changes to -CURRENT's : /etc/default/rc.conf to change the default hostname to "localhost". We have localhost.com as one of our domains here in the Village. So long as this change doesn't generate traffic to us in any way, shape, or form, I'd say go for it. Sniff your network for traffic to/from 204.144.255.150 to see if it does or not. There have been bugs in the past that would cause this to be the case. There have also been bugs in the past where machines (not necessarily FreeBSD machines) whose hostname was foo.com (for all values of foo) would try to use localhost.com as the loopback address. There is an RFC that specifies a "private use" top level domain, analogous to 192.168.0.0/16, 10.0.0.0/8, etc. The domain is ".local" so any default ending in ".local" should not conflict. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New netgraph features?
John Smith writes: Well, may be I didn't said exactly what I wanted to. If we use say, ksocket nodes as a tunnel, we will transfer the data - ok, but what about metadata? May be I should say 'to connect two netgraphs'? May be this is a lost cause, but that's why I'm asking. Yes, there would need to be some extra stuff. Here are some quick possibilities.. - We'd need to enhace the definition of a netgraph address to include, say, an IP address, eg.: $ ngctl msg 192.168.1.12:foo: blah blah - Encode control messsages in their ASCII forms for transit across the network - Pick a well known UDP port to be used for netgraph messages and data packets - Create a node type that could listen on this port (using ng_ksocket) and do the required encoding/decoding. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel
Lyndon Nerenberg writes: Mike This is primarily conditional on Cisco or some other party Mike making the specifications for etherchannel freely available. Mike The last time I went looking for any actual documentation on Mike how to format things on the wire, I drew a complete blank. http://www.cisco.com/warp/public/cc/techno/media/lan/ether/channel/prodlit/faste_an.htm It's pretty simple -- just an XOR of the bottom two bits of the destination MAC address to determine which interface in the bundle to send the packet out. If anyone is interested, I've got a "ng_one2many" netgraph node type that does simple round-robin packet delivery with no notion of failover. The intent is to eventually add support for different configurations, one of which would be Etherchannel, by configuring the node for the desired behavior. If you want to play with it, here is the current version: ftp://ftp.whistle.com/pub/archie/netgraph/ng_one2many.tgz -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: netgraph help(?)
Tony Landells writes: I'm trying to set up a multi-ethernet connection between two FreeBSD boxes so I can evaluate the performance of some of the network things (like IPSec) without bandwidth being an issue: -- | Machine A | 10.0.0.1 / fxp0-fxp5 \ 10.0.0.2 | Machine B | | |-- --| | | | \ (600 Mbps) / | | -- It looks like I need to use netgraph to do this, but I'm having trouble working out which pieces I need and how to put them together. I've looked at getting the user-PPP to manage it as multilink PPPoE, and I think I've worked out the "server" configuration, but can't work out what needs to be done on the client to make the multilink connection. Can anyone help me with this? An alternative might be to create a new netgraph node that round-robin's packets across the links. It would be easy to write and pretty short too, and avoids PPP overhead. I can help if you're interested. Hmm... ng_round_robin(4).. might be useful enough to add to FreeBSD anyway. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: something strange about FreeBSD 4.1-STABLE booting? (on an IBM laptop)
[ note: moving this thread to freebsd-mobile ] Nathan Vidican writes: Has anyone got FreeBSD running, successfully on an IBM ThinkPad A20M, (24U - PII 500/128megs Ram/6Gig HD) ? I have attempted to install twice now, both times have resulted in my having to replace the hardisk with a new one from IBM. Check freebsd-mobile. David Lebel [EMAIL PROTECTED] says he's got it working fine.. mine arrives next week :-) But earlier someone else posted with the same problem you had. Not sure what is going on with the boot process. David, did you install FreeBSD's boot0? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: c++ error
John Polstra writes: have both found edge cases where the gcc kluge loses. If you can come up with a reasonable test case that reproduces the problem, perhaps it can be PR'd to the GCC folks? Actually, I don't have a test case. I was only able to make it fail when I moved netinet/in.h out of /usr/include -- which disables the gcc kludge. I hope that Archie will be able to come up with a test case that demonstrates the failure. I was doing a build with DESTDIR=/usr/image and so in.h was actually being found in /usr/image/usr/include/netinet/in.h rather than the normal place, so this must be what happened to me as well. Ugh, I'm glad I got to skip C++ and go straight to Java :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
c++ error
This happens on 4.1-RELEASE: $ c++ ... foo.cc /usr/include/netinet/in.h:303: ANSI C++ forbids data member `ip_opts' with same name as enclosing class *** Error code 1 Any ideas? I tried __BEGIN_DECLS and __END_DECLS but that didn't help. I'm not a C++ expert. $ c++ --version $ 2.95.2 Thanks, -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: c++ error
John Polstra writes:
This happens on 4.1-RELEASE:
$ c++ ... foo.cc
/usr/include/netinet/in.h:303: ANSI C++ forbids data member `ip_opts' with
same name as enclosing class
*** Error code 1
Any ideas? I tried __BEGIN_DECLS and __END_DECLS but that didn't help.
I'm not a C++ expert.
$ c++ --version
$ 2.95.2
I can't duplicate it with this "program":
#include sys/types.h
#include netinet/in.h
I compile it with "cc -c test.cc" and get no errors. The diagnostic
Same here.
is valid, but there is a kludge in the compiler to make it work
anyway. See "src/contrib/gcc.295/cp/decl.c" around line 11515:
/* 9.2p13 [class.mem] */
if (declarator == constructor_name (current_class_type)
/* Divergence from the standard: In extern "C", we
allow non-static data members here, because C does
and /usr/include/netinet/in.h uses that. */
(staticp || ! in_system_header))
cp_pedwarn ("ANSI C++ forbids data member `%D' with same name as
enclosing class",
declarator);
That is a kludge if I ever saw one!!
Notice that it is permissive if the declaration is in a "system
header". This seems to work right, because if I create a local
directory "netinet" containing a copy of "in.h" and add "-I." to the
command line, then I get the diagnostic.
Is this the standard compiler installation, or are you using the ports
version? If it's the ports version, maybe it has an incorrect notion
of where the system headers are. I ran my tests using the standard
FreeBSD compiler installation.
This is the standard compiler in 4.1. However, the particular source
files being compiled are messy and it wouldn't surprise me that
they are triggering something.
On the other hand, nothing in the kernel actually uses "struct ip_opts",
though I haven't checked all of userland.. so we may just be able to
remove it.
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: c++ error
John Polstra writes: On the other hand, nothing in the kernel actually uses "struct ip_opts", though I haven't checked all of userland.. so we may just be able to remove it. From netinet/in.h it looks like a couple of [gs]etsockopt calls use it. Search for "ip_opts" just past that structure declaration. Oh, duh.. I was only checking C files.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.1 Release....MIIBUS
Warner Losh writes: : not marked. I noticed that 4.1 Release miibus is still not : marked as (required), is it no longer required, or is it still : not marked? I ahven't tried compiling it with miibus commented : out, I'm just assuming it's still required miibus is still required for any ethernet card with a mii. Which is basically all of them produced in the last few years. my trusty ne2000 doesn't need it :-) Would you ever want "miibus" even if you're NOT using any of the cards that require it? I guess you might need it to be able to KLD load one of those drivers.. ? But that's no argument becuse you could just have a miibus.ko that was a dependency of those drivers. So why is it a separate option? -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.1 Release....MIIBUS
Warner Losh writes: : So why is it a separate option? because it is a driver. Why is pci a separate driver? While most computers have it, not all do. Likewise with miibus. Ah.. but this analogy is not exact, because (for example) "device ed0" does not require PCI, wheras all of these miibus drivers do.. But you're probably right, since it's a driver maybe that's a good enough reason. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.1 Release....MIIBUS
Archie Cobbs writes: But you're probably right, since it's a driver maybe that's a good enough reason. ^^ Oops, meant "bus" instead of "driver" there.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CVS question
Nate Williams writes: I hope current versions of CVS force the dates to be the same on an import. I haven't checked to see whether that's the case or not. Suggestions like this would be good to send to the new CVS maintainers. Checkout www.cvshome.org, and send in a bug report, if you would please. You probably know CVS bugs better than many of the maintainers.:) Done. Thanks, -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CVS question
John Polstra writes:
$ cvs co -D 'January 18, 1999 0:00' freebsd/src/usr.sbin/xntpd/lib/ranny.c
Perhaps version 1.1.1.2 would be correct, but instead you get 1.1.
CVS has a heuristic that does the wrong thing for this particular
file. The code is around line 3252 of src/contrib/cvs/src/rcs.c in
the function RCS_getdate():
if (! STREQ (cur_rev, "1.1"))
return (xstrdup (cur_rev));
/* This is 1.1; if the date of 1.1 is not the same as that for the
1.1.1.1 version, then return 1.1. This happens when the first
version of a file is created by a regular cvs add and commit,
and there is a subsequent cvs import of the same file. */
p = findnode (rcs-versions, "1.1.1.1");
if (p)
{
vers = (RCSVers *) p-data;
if (RCS_datecmp (vers-date, date) != 0)
return xstrdup ("1.1");
}
It compares the dates on the theory that an import will set
identical dates in revisions 1.1 and 1.1.1.1. But in the file you
mentioned, they are off by 1 second. So CVS doesn't recognize it as
an import.
revision 1.1
date: 1993/12/21 18:36:22; author: wollman; state: Exp;
revision 1.1.1.1
date: 1993/12/21 18:36:23; author: wollman; state: Exp; lines: +0 -0
Probably the import straddled the seconds boundary. I hope current
versions of CVS force the dates to be the same on an import. I
haven't checked to see whether that's the case or not.
Hmm.. sounds like we should do one or both of these things..
1/ Fix the bug in CVS that caused the import to set two different dates
2/ Modify this cvs file to set the dates to be the same
What do you think?
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
CVS question
Consider this source file: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/xntpd/lib/Attic/ranny.c Question: what version should this command checkout? $ cvs co -D 'January 18, 1999 0:00' freebsd/src/usr.sbin/xntpd/lib/ranny.c Perhaps version 1.1.1.2 would be correct, but instead you get 1.1. It seems CVS is being inconsistent: - If you had done a 'head' checkout on that date you would have gotten 1.1.1.2 - If you later do a 'head' checkout, and specify that date, you get 1.1 What am I missing here.. ? Has this behavior in CVS changed at some point? Thanks, -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ether_ifattach() issue
Dennis writes:
The change in 4.1 to ether_ifattach() needs a check to see if the device is
already attached.
calling ether_ifattch() with a device already attached will lock up the
system consistently.
No interface should be attached twice, Ethernet or other, right?
So try this patch and find out which driver is broken.
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Index: sys/net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.91
diff -u -r1.91 if.c
--- if.c2000/07/16 01:46:42 1.91
+++ if.c2000/08/06 19:42:47
@@ -146,6 +146,17 @@
inited = 1;
}
+#ifdef INVARIANTS
+ {
+ struct ifnet *qent;
+
+ TAILQ_FOREACH(qent, ifnet, if_link) {
+ KASSERT(qent != ifp, ("%s%d: already attached",
+ ifp-if_name, ifp-if_unit));
+ }
+ }
+#endif
+
TAILQ_INSERT_TAIL(ifnet, ifp, if_link);
ifp-if_index = ++if_index;
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ether_ifattach() issue
Neil Blakey-Milner writes: No interface should be attached twice, Ethernet or other, right? So try this patch and find out which driver is broken. I think the concern was because the semantics to attach devices changed, meaning that drivers from before no longer work. Hmm.. my understanding was that it was never OK to attach the same interface twice (without detaching in between). So if this behavior worked before then it was just "luck". In any case, IMHO in the future it doesn't make sense to allow an interface to attach twice... what would that mean anyway? Admittedly there may be a backward compatibility problem, but it seems like the origin of the problem is in the driver, not the ether_attach() routine. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a quick one
FengYue writes: Hi there, a quick one. Is getpeername() considered expensive? Would it be much better if I cache the result myself instead of calling it everytime on the connected socket(returned from accept) to find out which IP it connects to? It's not particularly expensive compared to other system calls.. but if you find system calls in general expensive, then it would certainly count as one :-) I'd say it's unlikely that this kind of optimization would be worth the trouble for a 'normal' application. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: odd accept(2) behavior
Greg Thompson writes: i'm seeing some fairly odd behavior from accept(2) when the connecting socket goes away at just the right time. the timing is fairly funky, so i don't know if i can easily whip up a repro for this, but what i'm seeing is: accept returns a positive value (ie: not an error), but sets the addrlen to zero. a subsequent call to getsockname with the new socket returns -1 and sets errno to ECONNRESET. Everything sounds normal/expected except the part about addrlen being set to zero. That sounds like a bug. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Mike Smith writes:
Archie - I'd really appreciate a pointer to an example of using the
ng_parse code to pick up this sort of data, if you can recommend
something to help me get my head around it quickly (I've looked but slid
off sideways so far...).
Just to clarify.. a couple of things about the ng_parse stuff.
(I'm not claiming this is the right thing to use for modules,
just trying to clarify give more information about it).
Basically, it contains routines for converting between ASCII and
binary data; there are two main components..
(a) An infrastructure for doing completely arbitrary conversion,
provided that you are willing to write your own encode and
decode routines (i.e., the functions of type ng_parse_t
and ng_unparse_t, which are pointed to by the struct
ng_parse_type).
(b) Several pre-defined parse types, for example:
Integer types (8, 16, 32, and 64 bit)
String types (fixed and variable length)
C arrays (fixed and variable length)
C structures (including 'variable length structures')
Typically you either use a predefined simple type, or define a new
type by 'subclassing' the pre-defined structure or array types and
supplying some type-specific info that describes the structure or array.
As an example, see the 'struct ng_tee_hookstat' in ng_tee.h:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_tee.h?rev=1.3
/* Statistics structure for one hook */
struct ng_tee_hookstat {
u_int64_t inOctets;
u_int64_t inFrames;
u_int64_t outOctets;
u_int64_t outFrames;
};
Below it is the NG_TEE_HOOKSTAT_INFO definition which defines the
specifics of the structure for the parse type: four 64 bit fields:
/* Keep this in sync with the above structure definition */
#define NG_TEE_HOOKSTAT_INFO{ \
{ \
{ "inOctets", ng_parse_int64_type}, \
{ "inFrames", ng_parse_int64_type}, \
{ "outOctets",ng_parse_int64_type}, \
{ "outFrames",ng_parse_int64_type}, \
{ NULL }, \
} \
}
Now look in ng_tee.c where the parse type corresponding to a
'struct ng_tee_hookstat' is defined:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_tee.c?rev=1.8
/* Parse type for struct ng_tee_hookstat */
static const struct ng_parse_struct_info
ng_tee_hookstat_type_info = NG_TEE_HOOKSTAT_INFO;
static const struct ng_parse_type ng_tee_hookstat_type = {
ng_parse_struct_type,
ng_tee_hookstat_type_info,
};
The parse type we're defining is 'ng_tee_hookstat_type' which is
a 'subclass' of ng_parse_struct_type (a predefined type from
ng_parse.c), with the type-specific info 'ng_tee_hookstat_type_info'.
In ASCII form one of these 'struct ng_tee_hookstat' structures might
look like this:
{ inOctets=123 inFrames=27 outOctets=1033 outFrames=328 }
(The syntax for the predefined array and structure types is described
in ng_parse.h).
At some point I'd like to edit the files so that they can be compiled
either in user or kernel mode.
FYI, ng_parse is completely independent from the rest of netgraph
(i.e., the rest of netgraph is not required).
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Warner Losh writes: In message [EMAIL PROTECTED] "Gary T. Corcoran" writes: : I was wondering if you (or anyone on this list) has had time : to add module parameters to kldload? (and before anyone suggests : it, sorry, but I am barely able to squeeze out enough time to : even work on this unofficial driver, I can't work on kldload) You can use the hint mechanism that we've developed for other things. Another possibility is the netgraph binary - ASCII conversion stuff: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_parse.h?rev=1.3 -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Gary T. Corcoran writes: : I was wondering if you (or anyone on this list) has had time : to add module parameters to kldload? (and before anyone suggests : it, sorry, but I am barely able to squeeze out enough time to : even work on this unofficial driver, I can't work on kldload) You can use the hint mechanism that we've developed for other things. Another possibility is the netgraph binary - ASCII conversion stuff: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_parse.h?rev=1.3 Are you suggesting that these routines could be used to easily add parameters to kldload? (hint, hint) grin :-) No, I know it's not that easy. We need to be able to do things like have "TransmissionMode=4" on the kldload command line, and have that parse the decimal value 4, and then go into the module and set the value of the TransmissionMode variable to actually be 4 immediately after loading the module into memory, before any of its subroutines are called. This is what the Linux module loader allows, and it's extremely useful... This is the kind of thing ng_parse.c can do. In fact kldload could just pass the parameters as a single, opaque ASCII string and the kernel (the KLD, actually) can decode it back into a binary C structure using the ng_parse routines. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot/kernel debugging
Nick Hibma writes: In general it is well possible to single step anything in the kernel. You might find occasions where things stop working, and odd cases were things all of a sudden start working, but normally, apart from hardware things, most things are not time critical, or create problems through spin locks. You can single step at boot time, by setting the flags in the loader. set boot_ddb# jump to debugger set boot_gdb# use remote gdb for debugging by default Also don't for get 'sysctl -w debug.enter_debugger=ddb' (or gdb) to enter the debugger from the command line. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need help debugging a crash (PR kern/18685)
Thomas Faehnle writes: I'm trying to assist in debugging the crash reported as kern/18685-- apparently Greg is unable to reproduce the problem on his machine. Have you tried hooking up another machine via serial console and using gdb? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
panic reading routing socket
The patch below adds some INVARIANTS consistency checks to socket
receive operations. This was motivated by a recurring "receive 1"
panic that happens every couple of weeks on a 3.4-RELEASE based
system.
When I use this patch I get an immediate panic as the system comes
up, when routed tries to read the routing socket (line 724 of
uipc_socket.c (3.4-REL post patch)).
But I can't figure out if the panic is occurring because the patch
is bogus (i.e., checking too stringently) or if there really is a
bug in there somewhere.
Any thoughts appreciated..
Thanks,
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
diff -ur /usr/src/sys/kern/uipc_socket.c ./uipc_socket.c
--- /usr/src/sys/kern/uipc_socket.c Sun Aug 29 09:26:11 1999
+++ ./uipc_socket.c Mon May 8 11:44:21 2000
@@ -55,6 +55,21 @@
#include machine/limits.h
+#ifdef INVARIANTS
+#define SPLNETCHECK() do {\
+ int s1, s2; \
+ s1 = splnet(); \
+ s2 = splnet(); \
+ if (s1 != s2) \
+ panic("%s: !splnet", __FUNCTION__); \
+ splx(s1); \
+ } while (0)
+#define SBCHECK(sb)sbcheck(sb)
+#else
+#define SPLNETCHECK() do { } while (0)
+#define SBCHECK(so)do { } while (0)
+#endif
+
struct vm_zone *socket_zone;
so_gen_t so_gencnt; /* generation count for sockets */
@@ -629,6 +644,7 @@
if (error)
return (error);
s = splnet();
+ SBCHECK(so-so_rcv);
m = so-so_rcv.sb_mb;
/*
@@ -678,6 +694,7 @@
error = EWOULDBLOCK;
goto release;
}
+ SBCHECK(so-so_rcv);
sbunlock(so-so_rcv);
error = sbwait(so-so_rcv);
splx(s);
@@ -686,6 +703,7 @@
goto restart;
}
dontblock:
+ SBCHECK(so-so_rcv);
if (uio-uio_procp)
uio-uio_procp-p_stats-p_ru.ru_msgrcv++;
nextrecord = m-m_nextpkt;
@@ -695,6 +713,7 @@
if (psa)
*psa = dup_sockaddr(mtod(m, struct sockaddr *),
mp0 == 0);
+ SBCHECK(so-so_rcv);
if (flags MSG_PEEK) {
m = m-m_next;
} else {
@@ -702,8 +721,10 @@
MFREE(m, so-so_rcv.sb_mb);
m = so-so_rcv.sb_mb;
}
+ SBCHECK(so-so_rcv);
}
while (m m-m_type == MT_CONTROL error == 0) {
+ SBCHECK(so-so_rcv);
if (flags MSG_PEEK) {
if (controlp)
*controlp = m_copy(m, 0, m-m_len);
@@ -724,6 +745,7 @@
m = so-so_rcv.sb_mb;
}
}
+ SBCHECK(so-so_rcv);
if (controlp) {
orig_resid = 0;
controlp = (*controlp)-m_next;
@@ -736,6 +758,7 @@
if (type == MT_OOBDATA)
flags |= MSG_OOB;
}
+ SBCHECK(so-so_rcv);
moff = 0;
offset = 0;
while (m uio-uio_resid 0 error == 0) {
@@ -762,13 +785,16 @@
* block interrupts again.
*/
if (mp == 0) {
+ SBCHECK(so-so_rcv);
splx(s);
error = uiomove(mtod(m, caddr_t) + moff, (int)len, uio);
s = splnet();
+ SBCHECK(so-so_rcv);
if (error)
goto release;
} else
uio-uio_resid -= len;
+ SBCHECK(so-so_rcv);
if (len == m-m_len - moff) {
if (m-m_flags M_EOR)
flags |= MSG_EOR;
@@ -801,6 +827,7 @@
so-so_rcv.sb_cc -= len;
}
}
+ SBCHECK(so-so_rcv);
if (so-so_oobmark) {
if ((flags MSG_PEEK) == 0) {
so-so_oobmark -= len;
@@ -814,6 +841,7 @@
break;
}
}
+ SBCHECK(so-so_rcv);
if (flags MSG_EOR)
break;
/*
@@ -837,19 +865,23 @@
if (m)
nextrecord = m-m_nextpkt;
}
+ SBCHECK(so-so_rcv);
}
+ SBCHECK(so-so_rcv);
if (m pr-pr_flags PR_ATOMIC) {
Re: Help with SIOCADDMULTI, IFF_ALLMULTI and IFF_PROMISC
Robert Watson writes: You should go promiscuous to multicast. If the card doesn't support that, you should go fully promiscuous and drop unicasts that aren't to you. (Make sure you don't block packets that bpf is going to want to see). Also, if you want bridging support, you have to bridge before doing the filtering. Really, the filtering on ``appropriateness'' should only occur when the packet is about to enter ether_input(). Speaking of which, I'd really like to see bridge support getting added to all new NIC drivers from now on. However, the current bridge interface leaves something to be desired... I'm working on fixing this.. see discussion on freebsd-net. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
Hellmuth Michaelis writes: 2. We should come up with a 'standard' netgraph control message API for an ISDN basic rate interface, and have i4b implement this interface. Then mpd/ppp/etc can "know" this interface and therefore work automatically with any ISDN BRI device. Here is the interface that we use at Whistle: ftp://ftp.whistle.com/pub/archie/netgraph/ng_tn.h (note: the switch types are #defined in another file but include all of the usual suspects: ETSI, NI-1, ATT, DMS100, etc.) The problem here is, that the Whistle ISDN stack has a fundamentally different view of the world than i4b has :-) As far as i understood it, the Whistle ISDN stack is almost completely configurable by using netgraph messages whereas i4b is configured by its isdnd config file. I have made some experiments with mppd over the i4b netgraph b-channel interface and it works beautifully here without any additional configuration messages necessary. But i have no idea, if the real world demands some control messages, such as dial, dial a number, hangup etc. Yes, our way of doing things was of course designed for our particular application. It depends on what you want to do with an 'ISDN node'. The /dev/i4b interface is actually pretty close to equivalent to our netgraph control message API. The main differences seem to be: - Our API is strictly limited to ISDN operation, e.g., there are no equivalents to I4B_TIMEOUT_UPD, I4B_UPDOWN_IND, or MSG_IDLE_TIMEOUT_IND and no connection to sppp(8) - Our API allows more ISDN-related configuration, e.g., changing switch type. - Our API is at a slightly higher level.. we don't have the CDID_REQ or PROCEEDING_IND messages; when rejecting a call, you don't get to specify the cause code, it's always set to 21 for you, etc. So the /dev/i4b and our netgraph API are actually quite similar. Of course, a major difference is that with /dev/i4b you don't get the B-channels exposed as netgraph node hooks, which is very useful... but as you've shown already this is easy to add. This gets you a "half netgraphified" ISDN node. One thing that would be easy to do is to simply convert all of the /dev/i4b ioctl's directly into netgraph control messages. This doesn't really buy you anything much though -- really just a different interface for the same thing. But if there were future plans to do all kinds of wacky things with an ISDN device that would benefit by having it fully netgraphified, maybe this would be worth doing. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
Hellmuth Michaelis writes: to add a negraph interface to the B channels should be quite easy. If you need help I can prbably almost do most of it.. Its already in the development sources (Archie had a look at it already) and it works with mppd. It was really quite easy, although if Archies daemonnews article had been available at that time i wrote it, it would have been even easier :-) when this is done the netgraph PPP nodes (which can support these compression types will be usable. In the mppd i worked with (looking ... mpd3.0b1/mpd3.0b2) deflate was not present, predictor was not usable, bsd was not present. There were just hooks for M$ and stac (which you can not release obviously). Currently i'm using ppp instead of mppd mostly just because it supports deflate compression. I had a look at both mppd and ppp to see how the mentioned free stac compression would be integrateable and found them both similar, given they both come from iijppp. It looks like if it were a good idea if Brian and Archie would merge both to get the best features from each one into a common product ;-) Here is my list of things that 'should be done' at some point: 1. Implement the various PPP compression types as netgraph nodes, starting with Deflate, then maybe predictor-1, STAC (if we can do it legally), and MPPC (same thing). Once these exist, then mpd 'adapters' will have to be written for each one -- these are easy, they just decode the config-req's. I already have code for MPPC/MPPE, minus the proprietary STAC code and the patented RC4 algorithm, and am going to submit it after 4.0-REL as soon as somebody submits an RC4 implementation to /sys/crypto in the international repository. Mpd-3.x already has support for MPPC/MPPE. This is available on our ftp site.. ftp://ftp.whistle.com/pub/archie/netgraph/mppc.tgz 2. We should come up with a 'standard' netgraph control message API for an ISDN basic rate interface, and have i4b implement this interface. Then mpd/ppp/etc can "know" this interface and therefore work automatically with any ISDN BRI device. Here is the interface that we use at Whistle: ftp://ftp.whistle.com/pub/archie/netgraph/ng_tn.h (note: the switch types are #defined in another file but include all of the usual suspects: ETSI, NI-1, ATT, DMS100, etc.) -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
Juergen Lock writes: when this is done the netgraph PPP nodes (which can support these compression types will be usable. They could, but they don't yet, right? :) Maybe it still should be added to ijppp first cause debugging user processes is easier than the kernel... and at the usual isdn bri speeds a user process should still be pretty fast enough. That makes perfect sense.. just be sure to write the code so that it's easily ported to the kernel.. the main issues being mbuf's.. for that it's probably eassiest to just punt and copy each packet into a contiguous buffer. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
John Polstra writes: I already have code for MPPC/MPPE, minus the proprietary STAC code and the patented RC4 algorithm, I have read in several places that only the name "RC4" is trademarked, and that the algorithm itself is not patented. Is that not the case? Oops, my mistake.. you are correct as far as I know. What I should have said was "the non-exportable RC4 algorithm" because (also AFAIK) it's not exportable so we can't check it into freefall. We *can* check it in to the international repository but I don't know if anyone has done that yet, or if so what the header file looks like. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Help: interrupt timeout
My laptop running 3.4-RELEASE decided it doesn't want to boot. It was uncleanly shut down via the power switch by someone who thought they were shutting down a different machine. Now when it boots, running fsck gives this result: chip0: Intel 82439TX System Controller (MTXC) rev 0x01 on pci0.0.0 chip1: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.7.0 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.7.1 ... wdc0 at 0x1f0-0x3f7 irq 14 on isa wdc0: unit 0 (wd0): TOSHIBA MK6409MAV wd0: 6194MB (12685680 sectors), 13424 cyls, 15 heads, 63 S/T 512 B/S wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): MATSHITADVD-ROM SR-8171/058A, removable, accel, dma, iordis ... # fsck / *** /dev/rwd0s3a *** Last Mounted on / *** Root file system *** Phase 1 - Check Blocks and Sizes wd0: interrupt timeout (status 58rdy,seekdone error 0) wd0: wdtimeout DMA status 4 wd0: interrupt timeout (status 50rdy,seekdone error 1no_dam) wd0: wdtimeout DMA status 4 wd0: interrupt timeout (status 50rdy,seekdone error 1no_dam) wd0: wdtimeout DMA status 4 wd0: interrupt timeout (status 50rdy,seekdone error 1no_dam) wd0: wdtimeout DMA status 4 wd0: interrupt timeout (status 50rdy,seekdone error 1no_dam) wd0: wdtimeout DMA status 4 wd0: Last time I say: interrupt timeout. Probably a portable PC. (status 50rdy,seekdone error 1no_dam) Well, yes in fact it is a portable PC :-) It just seems to hang at this point, even though there seems to be disk activity (like it's continuously retrying). This machine has run fine under this kernel since I installed 3.4-REL a month ago or so. This same problem happens with the 3.4-REL GENERIC kernel. Before this, it was running fine with a 3.0++ kernel and never had this problem after many power cycles. Is there any hope in getting this machine to work again?? Howabout disabling DMA? Is there some way to do that? Thanks for any pointers.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Netgraph article
For anyone interested in reading about netgraph(4), including technical information about developing your own node types, etc., here is an article that I wrote for this month's Daemon News 'blueprints' column.. http://www.daemonnews.org/23/netgraph.html -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NETGRAPH patches (proposal)
Julian Elischer writes: It's because all packets sent by this node should have the node's address. If you don't have it then PPPoE cannot send a packet "FROM" thia node, as it has no idea of what this node's address is. So.. we can have two hooks, one that sets the host address and one that doesn't.. :-) In that case can we have one that also sets the destination address via arp? Now I think you are talking a separate node that implements such a protocol. Right.. ARP is an IP-specific protocol. Ethernet nodes should have no specific knowledge of ARP. But it would be easy to create an ARP node that sat between the IP stack and an Ethernet node... it would maintain an ARP cache, and when it saw an outgoing dest IP address that was unmapped would issue an ARP request, etc. It would listen to the incoming Ethertypes for IP and ARP coming up from the Ethernet node. This brings up another point.. to really do this correctly we would also need a 802.3/802.2 node type that decoded Ethertypes and SNAP headers. It would have a "downstream" hook that connected to the Ethernet node and also hooks for "ip", "arp", "appletalk", "aarp" (AppleTalk's ARP), "ipx", "ipv6", etc. Also, it could suport generic Ethertype hooks having names of the form "0x". Probably the raw Ethernet node type should not even know about 802.3 (the standard 14 byte Ethernet header and the 60 byte minimum packet length).. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NETGRAPH patches (proposal)
Maksim Yevmenkin writes: Here are some small patches for NETGRAPH. These are against -current cvsup'ed yesterday around 8:30pm EST. http://home.earthlink.net/~evmax/ng.tar.gz It also includes small test program (based on nghook). Compile and run it like: # ./a.out -a iface_name: divert NETGRAPH option in kernel config file is required. Here is the description. ng_ether node has two hooks ``divert'' and ``orphan''. It is possible to connect to the one of the hooks and intercept row Ethernet frames. But there is no clean way to intercept frame, do something and return it back to kernel. This patch provides additional hook ``divertin'' (mmm... name is not good, i think) for each ng_ether node. Implementation issues This will not work for ``orphan'' frames. Since kernel drops it anyway, i decided to leave it as it is. But is is possible to intercept ``orphan'' packets, change it, and write back to ``divertin''. The "divertin" hook is a useful idea.. after 4.0-REL we can check something in based on your patches... Thanks! -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NETGRAPH patches (proposal)
Yevmenkin, Maksim N, CSCIO writes: Here is the description. ng_ether node has two hooks ``divert'' and ``orphan''. It is possible to connect to the one of the hooks and intercept row Ethernet frames. But there is no clean way to intercept frame, do something and return it back to kernel. This patch provides additional hook ``divertin'' (mmm... name is not good, i think) for each ng_ether node. Implementation issues This will not work for ``orphan'' frames. Since kernel drops it anyway, i decided to leave it as it is. But is is possible to intercept ``orphan'' packets, change it, and write back to ``divertin''. The "divertin" hook is a useful idea.. after 4.0-REL we can check something in based on your patches... ok. i just have a dumb question. what is the big deal with updating ether_shost in ethernet header in ngether_rcvdata. since we are passing raw ethernet frame, why should we update ether_shost? wouldn't it be nice to make it optional? just another control message? I agree.. you should have to set the host address manually. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NETGRAPH patches (proposal)
Julian Elischer writes: ok. i just have a dumb question. what is the big deal with updating ether_shost in ethernet header in ngether_rcvdata. since we are passing raw ethernet frame, why should we update ether_shost? wouldn't it be nice to make it optional? just another control message? I agree.. you should have to set the host address manually. It's because all packets sent by this node should have the node's address. If you don't have it then PPPoE cannot send a packet "FROM" thia node, as it has no idea of what this node's address is. So.. we can have two hooks, one that sets the host address and one that doesn't.. :-) -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: raw socket, bpf, netgraph, etc
David Malone writes: Compile your kernel with options NETGRAPH and then each Ethernet interface is a netgraph node. Take control of it by connecting to the "divert" hook. I was trying to figure out if it is possible to route stuff out on a particular interface based on source address using netgraph. At the moment we have an NFS server which pretends to be two machines on the same subnet. To get this to work we're using a small hack in the ipfw divert code. I looked at the netgraph man pages and reckoned it might be possible to do somthing like: fxp0 / ng0 - bpf \ fxp1 then ifconfig ng0 up with both IP addresses and use the bpf to determine which ethernet card to transmit it on. However, I don't think this will work. First 'cos arp stuff will probably be broken and second because ng0 is a point to point device and won't correctly encapsulate packets for ethernet. You're right that that won't work .. you'd be sending raw IP frames on the wire without 14 byte Ethernet headers. Am I correct in thinking that this isn't currently possible with the net graph nodes currently available? I think so.. you would have to write a new new node type to add/strip the headers at least. That brings up a good point though.. the ng_iface(8) node type should allow it to configured as a non-point-to-point interface. Ah.. just looked at if_tun.c which does this.. it's trivial. I'll probably check something in after 4.0 then. But even with that change you'd need an add/strip headers thing. In fact, that's another node type I want to write.. just a simple thing that adds strips headers off packets... or this could be folded into the BPF node type (a BPF program returns a length, after all). -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: raw socket, bpf, netgraph, etc
Yevmenkin, Maksim N, CSCIO writes: i was thinking about netgraph. would't it be nice to have netgraph interface in each network driver? You already do. See ng_ether(8). Compile your kernel with options NETGRAPH and then each Ethernet interface is a netgraph node. Take control of it by connecting to the "divert" hook. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW / IP Filter question
Jeroen Ruigrok/Asmodai writes: I would have thought you would use the tee option in ipfw for this, but its not implemented yet according to my man pages, so I was wondering if there was another way to do this, cause it makes traffic analysis a hell of a lot easier if I can do this rather than having to sniff it with bpf or something. Didn't CURRENT add the tee option by now? Yes, I added ``ipfw tee'' to current.. however, it's not completely perfect yet but should be usable. FYI, you can combine ``tee'' with ngctl(8) and netgraph's ksocket node type to get a tcpdump-like effect.. eg: $ ipfw add 100 tee 1234 icmp from any to any in icmptype 8 $ ngctl Available commands: [ ... snip ... ] + mkpeer ksocket foo inet/raw/divert + msg foo bind inet/0.0.0.0:1234 Rec'd data packet on hook "foo": : 45 00 00 54 99 f7 00 00 ff 01 e8 be c3 4c cd 07 E..T.L.. 0010: c3 4c cd 51 08 00 51 7e 4f c8 00 00 a6 23 a3 38 .L.Q..Q~O#.8 0020: 15 5a 0d 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 .Z.. 0030: 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 !"# 0040: 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%'()*+,-./0123 0050: 34 35 36 37 4567 + Rec'd data packet on hook "foo": : 45 00 00 54 99 fe 00 00 ff 01 e8 b7 c3 4c cd 07 E..T.L.. 0010: c3 4c cd 51 08 00 a3 a6 50 c8 00 00 a8 23 a3 38 .L.QP#.8 0020: c8 31 05 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 .1.. 0030: 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 !"# 0040: 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%'()*+,-./0123 0050: 34 35 36 37 4567 + quit -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: T1 / E1 PCI card for FreeBSD?
Louis A. Mamakos writes: What we are looking for is just 30 x 64 kbit incoming ISDN channels for remote access to Internet. "remote access concentrator". channels. Some of them might be combined with others to provide Nx64kb/s I see the Portmaster 3 can bond channels even across PM3 chassis, but we would not need anything so fancy as that, as least in the first phase. This was different from what I had described, which is combining two or more 64kb/s channels into an aggregate channel of higher capacity; essentially a fractional-E1 (or T1). In my (biased) opinion, the right way to handle this is to make the card appear as a netgraph node. You configure it however you want with control messages, then attach netgraph interfaces, etc. Isn't this what Poul did? -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Removing interfaces
Warner Losh writes: : With all the PCMCIA card stuff going on, is it now possible to : remove a networking interface in FreeBSD (from within the kernel)? : : If so could someone show me an example how. I'd like to implement : this in the ng_iface(8) netgraph node type. if_detach() is supposed to do this, but there are theoretical problems with our implementation of it. Also, there needs to be some way to propigate the "gone"ness of the interface generically rather than the ad-hoc way we do it now. Thanks, that works great (so far :-) -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Removing interfaces
With all the PCMCIA card stuff going on, is it now possible to remove a networking interface in FreeBSD (from within the kernel)? If so could someone show me an example how. I'd like to implement this in the ng_iface(8) netgraph node type. Thanks, -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to get a dynamically assigned major number?
Dear kernel device gurus,
I'm trying to get the security/skip port working for 4.0. Right
now it's marked BROKEN due to all the device changes earlier in
the year, and was wondering if someone could help advise me how do
update it..
Below is the current code that works with -stable. How do I get
a major number for the cdevsw I need to add? It looks like cdevsw_add()
no longer treats zero as 'assign me one dynamically'.
I'd really like to get this fixed soon (ie, before 4.0).. I'm sure
it's something simple I'm missing.
Thanks!
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
-- excerpt from current code
struct cdevsw skipdevsw = {
skip_ifopen, skip_ifclose, skip_ifread, skip_ifwrite, skip_ifioctl,
#if 0
nullstop, noreset, nodevtotty,
#endif
skip_ifpoll, nommap, nostrategy,
"skip", NULL
};
static struct cdevsw*old_dev;
static u_long skip_major;
/*
* Handle loading and unloading of the SKIP module.
*/
static int
skip_mod_event(module_t mod, int event, void *data)
{
int error = 0;
dev_t dev;
switch (event) {
case MOD_LOAD:
/* Add character device, getting assigned a major number */
dev = (dev_t) -1;
if ((error = cdevsw_add(dev, skipdevsw, old_dev)) != 0) {
log(LOG_ERR, "skip: can't add device\n");
break;
}
skip_major = major(dev);
/* Initialize SKIP itself */
if ((error = skip_init()) != 0) {
/* XXX should remove char device */
log(LOG_ERR, "skip: init failed\n");
break;
}
log(LOG_INFO, "skip: device major=%lu, driver loaded\n",
skip_major);
break;
case MOD_UNLOAD:
/* Uninitialize SKIP */
if ((error = skip_uninit()) != 0) {
log(LOG_INFO, "skip: uninit failed\n");
break;
}
/* Replace original device driver (if any) */
dev = makedev(skip_major, 0);
(void) cdevsw_add(dev, old_dev, NULL);
break;
default:
error = EOPNOTSUPP;
break;
}
return(error);
}
static moduledata_t skip_mod = {
"skip",
skip_mod_event,
NULL
};
DECLARE_MODULE(skip, skip_mod, SI_SUB_PROTO_END, SI_ORDER_MIDDLE);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: printf() from KLD
Alex writes: This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED] Be sure to reply to that address. Hello, I use printf() function from my KLD for debugging. Always, when the kernel call printf, I see two same line, like : Dec 9 15:40:10 techno /kernel: message Dec 9 15:40:10 techno /kernel: message How can I remvoe second line? Thank you. man syslog.conf Your message is matching more than one rule (eg, "root" and "console"). -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Crypto in the kernel: where how?
What is the plan (if any) for including crypto stuff in the kernel? As time goes on this will be more and more needed, eg. for IPSec and other VPN applications. It would be nice if we had a /usr/src/sys/crypt directory, plus whatever export-controlled firewalling silliness is necessary. Proposal.. (to get things started) - Add /usr/src/sys/crypt directory - Put exportable crypto stuff in it, eg, md5.c. - Put non-exportable crypto stuff in the international repository (which is where?) .. and possibly a separate US repository (?) (Or can the CVSup mirrors be configured not to mirror it?) My ulterior motive is to checkin netgrapph/ng_mppc.c which adds MPPE/MPPC support for PPTP. However it's useless without an [A]RC4 implementation. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New mpd with netgraph and PPTP
A new version of 'mpd', a multi-link PPP daemon, is available as a beta release from Whistle Communications under the Whistle license (BSD style). * This new version is completely netgraph(4) based, which means that all of the negotiation protocols (IPCP, LCP, etc) are handled in user-land, while all data transmission, compression, encryption, etc. is handled strictly in the kernel. This approach combines the configuration flexibility of a user-mode PPP daemon with the speed of a kernel-only PPP daemon, not to mention the wide device type and protocol support of netgraph. * This version also includes support for the Point-to-Point Tunneling Protocol (PPTP), in both client "dial-in" mode and LAN-LAN VPN, and is compatible with Microsoft's Dial-Up Networking VPN adapter. To get the new mpd: 1. Update your -stable or -current system from CVS (ie, today's!) and make world (or at least build and install a new kernel, kernel includes, netgraph modules, and libnetgraph). 2. Run pkg_delete on any existing mpd port on your machine 3. Blow away /usr/ports/net/mpd, and replace it with this: ftp://ftp.whistle.com/pub/archie/mpd/port.tgz 4. Build and install the new port. Any bug reports, suggestions, etc. are greatly appreciated. I'd also be interested to hear if anyone does any speed comparisions between this version of mpd and other FreeBSD PPP implementations. Cheers, -Archie PS: We also have an MPPE (Microsoft Point-to-Point encryption) implementation (as a netgraph module). This allows Microsoft clients' PPTP connections to be encrypted, though the security of MPPE is not very strong. However, it includes RC4, which is patented, so you must get your own implementation of RC4 (legally!) and compile the node yourself. Let me know by email if you're interested in trying this out too. PPS: Does not understand PPPoE yet.. use 'ppp' for that. _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: About divert socket
Witthaya Panichprechakorn writes: I use divert socket to captuer packets. I found that when I capture a set of fragmented packets, there are 2 incoming reassembled packets. The sin_port of sockaddr_in of the first packet is 0, and of another packet is the port number, which it bound to. However, when the packet is not fragmented, there is only one incoming packet with sin_port of sockaddr_in equals to the port number, which it bound to, similar to the second captured packet when framentation occured. What is the actual process when a set of fragmented packets is arrived? Why the system should divert two incoming packets? What version of FreeBSD? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd is jumpy
Brian Dean writes: No dropped packets, but definitely some occasional long delays before I get the echo. However, I must concede, based on other respondants, that something else must be going on and I cannot necessarily attribute this to divert/firewall/natd. However, the above numbers don't really illustrate the long response times that I experience while typing at the shell prompt, or in elm. It's really frustrating. I have an external US Robotics Sportster modem and I can see the rx/tx leds which are both off during the times when there was a delay, so I can confirm that there was no other line-contention on my end. Could be you have a noisy line and your modem error correction is kicking in. Try configuring your modem to disable error correction and see if it changes things. This is consistent with your rx/tx lights -- typically they only light up when there's traffic on the serial line (not the telephone line). -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem about Raw IP socket
Sunthiti Patchararungruang writes: I have to create a route program for my thesis. Its operation is different from normal packet forwarding. Therefore, I need to forward all packets instead of using normal packet forwarding in FreeBSD kernel. I capture packets via Divert socket. It works well. I can grap IP packket including its header. However, I use normal Raw IP socket to write the packets to selected next-hop. I use socket option SO_DONTROUTE and IP_HDRINCL with my Raw IP socket and use "sendto" to write packets with "sockaddr" set to the IP of the next-hop-gateway. The sendto command always return error with errno=22. How can I solve this error? 22 = EINVAL. That can happen if your IP header is not well-formed. The relevant file is /usr/src/sys/netinet/raw_ip.c. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to use gdb to catch a panic
Zhihui Zhang writes: Thanks for your reply. What confuses me is that when I use commands "gdb" (enter remote protocol mode) and "step" on the target machine, the debugging machine takes control (it executes "target remote /dev/cuaa1"). In this case, how can I run anything on the target machine to trigger a panic? I'm not sure if this answers your question, but the command sysctl -w debug.cebugger=1 will cause the kernel to stop and return your gdb prompt. Then you could call the function panic() directly if you wanted. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to use gdb to catch a panic
Julian Elischer writes: uh archie, that's a whistle specific sysctl :-) Are you sure? We should check it in, it's very useful! I'm not sure if this answers your question, but the command sysctl -w debug.cebugger=1 ^ should be "debugger" will cause the kernel to stop and return your gdb prompt. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ping - sized tests with 0% and 100% packet loss! Any ideas?
Josef Karthauser writes: A wierd one. I'm trying to track down a packets size (I believe) problem on my network. During ping testing I've come across the following strange which I don't understand. Using various sized packets ($n) with: ping -f -c 300 -s $n localhost I'm getting results that I wouldn't expect: SizePacketLoss 1 14% 2-100% 11 100% 12 0% 13 100% 14 0% 15 100% etc. Happens to me to on -current, but not -stable. With -current's ping on stable it doesn't happen, and with -stable's ping on -current it still happens. Therefore it must be a kernel bug. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
Mike Smith writes: I expect as much, but when I tried to make an IPX KLD, it paniced the system on unload. I will test the FFS KLD soon though. Panic on unload usually means that the code in question isn't designed to unload. 8) Such code should return an error instead of allowing the unload to proceed :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Make question
Am I confused or is there a bug in make(1).. ? Why is 'make foo' failing but 'gmake foo' succeeding? $ cat makefile foo: var1=yes; test "$$var1" = "no" var2=". $$var2"; echo OK $ make foo var1=yes; test "$var1" = "no" var2=". $var2"; echo OK *** Error code 1 Stop in /root. $ gmake foo var1=yes; test "$var1" = "no" var2=". $var2"; echo OK OK This happens on -current and -stable. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.3-STABLE panic in m_copym
[EMAIL PROTECTED] writes:
I have a Compaq Proliant 3000 (2 x PII-333) running 3.3-STABLE which has
crashed several times with the following backtrace:
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc0144299 in panic (fmt=0xc023eb04 "m_copym") at ../../kern/kern_shutdown.c:446
#2 0xc015ac7e in m_copym (m=0xc141ae80, off0=10788, len=1216, wait=1) at
../../kern/uipc_mbuf.c:435
#3 0xc019286a in tcp_output (tp=0xd0be8960) at ../../netinet/tcp_output.c:505
#4 0xc0194106 in tcp_usr_send (so=0xd0ae9640, flags=0, m=0xc1420680, nam=0x0,
control=0x0, p=0xd0e95b20) at ../../netinet/tcp_usrreq.c:395
#5 0xc015c4b2 in sosend (so=0xd0ae9640, addr=0x0, uio=0xd0ee5f10, top=0xc1420680,
control=0x0, flags=0, p=0xd0e95b20)
at ../../kern/uipc_socket.c:530
#6 0xc01525dc in soo_write (fp=0xc210c600, uio=0xd0ee5f10, cred=0xc1fce600,
flags=0) at ../../kern/sys_socket.c:82
#7 0xc014f46a in dofilewrite (p=0xd0e95b20, fp=0xc210c600, fd=7, buf=0x806f0f4,
nbyte=8192, offset=-1, flags=0)
at ../../kern/sys_generic.c:363
#8 0xc014f373 in write (p=0xd0e95b20, uap=0xd0ee5f94) at
../../kern/sys_generic.c:298
#9 0xc021f39b in syscall (frame={tf_es = 39, tf_ds = -1078001625, tf_edi =
671806342, tf_esi = 7, tf_ebp = -1077949676,
tf_isp = -789684252, tf_ebx = 0, tf_edx = 434759, tf_ecx = 0, tf_eax = 4,
tf_trapno = 7, tf_err = 2, tf_eip = 134533700, tf_cs = 31,
tf_eflags = 518, tf_esp = -1077949700, tf_ss = 39}) at
../../i386/i386/trap.c:1100
#10 0xc020b2ac in Xint0x80_syscall ()
The panic is the following loop in m_copym:
while (off 0) {
if (m == 0)
panic("m_copym");
if (off m-m_len)
break;
off -= m-m_len;
m = m-m_next;
}
so it seems to be running off the end of the mbuf chain before having
verified the whole length. Following the m_next pointers, starting with
the mbuf pointer from the calling routine, I get a total of 5 mbufs in
this chain, with the following lengths:
0xc141ae80 2048
0xc13fef80 2008
0xc1446e00 2048
0xc147fe80 872
0xc1420680 1216
This may or may not be helpful, but..
Packet mbuf's contain redundant information: the header mbuf contains
the total length (m-m_pkthdr.len), which must be equal to the sum of
the lengths of the individual mbuf's in the chain (m-m_len).
I think these numbers getting out of sync is a common source of bugs.
For example, code that builds an mbuf chain by concatenating mbuf's
forgets to update the m-m_pkthdr.len field.
You might look at where the packet originated, ie in dofilewrite() (?)
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: bind(2) sets errno to undocumented EAGAIN?
Charles Randall writes: Under what conditions does bind(2) set errno to EAGAIN? The 3.2R bind(2) manual page does not list that as a valid value for errno when bind returns -1. Please file a PR so this gets fixed. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
Christopher Seiwald writes:
But as I'm proposing a change to a fairly sensitive piece of code, I'd
like to keep the change as modest as possible.
How about this?
Index: qsort.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.7
diff -u -r1.7 qsort.c
--- qsort.c 1997/02/22 15:03:14 1.7
+++ qsort.c 1999/08/21 01:35:35
@@ -153,7 +153,7 @@
pb += es;
pc -= es;
}
- if (swap_cnt == 0) { /* Switch to insertion sort */
+ if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
for (pm = (char *)a + es; pm (char *)a + n * es; pm += es)
for (pl = pm; pl (char *)a cmp(pl - es, pl) 0;
pl -= es)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
Christopher Seiwald writes:
But as I'm proposing a change to a fairly sensitive piece of code, I'd
like to keep the change as modest as possible.
How about this?
Index: qsort.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.7
diff -u -r1.7 qsort.c
--- qsort.c 1997/02/22 15:03:14 1.7
+++ qsort.c 1999/08/21 01:35:35
@@ -153,7 +153,7 @@
pb += es;
pc -= es;
}
- if (swap_cnt == 0) { /* Switch to insertion sort */
+ if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
for (pm = (char *)a + es; pm (char *)a + n * es; pm += es)
for (pl = pm; pl (char *)a cmp(pl - es, pl) 0;
pl -= es)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: anybody love qsort.c?
Narvi writes: Doesn't the qsort just switch to isort *if* the partition to sort is short enough? That's exactly Christopher's point. It should do this but it doesn't. The code is complex but from a quick glance it appears that the decision to switch to insertion sort does not depend on the total array length. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: anybody love qsort.c?
Christopher Seiwald writes: The FreeBSD qsort implementation has a rather nasty degenerate case. If you have data that partitions exactly about the median pivot, yet which is unsorted in either partition, you get get treated to an insertion sort. Example: 1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11 qsort picks 10 as the median, does no swaps on its first pass, and so decides to switch to an insertion sort. The idea is that if no swaps occur, the data is likely to be nearly already sorted and a good candidate for insertion sort. This turns out to be a (very) bad idea if you have some unsorted data buried in the middle of a (very) large dataset. The implementation claims to come from Bentley and McIlroy's paper, "Engineering a Sort Function," and this is largely true, but the insertion sort optimization(?) isn't in that paper. The GNU qsort.c only does an insertion sort if it is below a certain threshhold in size, and so never attempts such a sort on the whole dataset. (The GNU qsort does a number of other things pooh-poohed in the Bentley paper.) It's a pretty straightforward change to bypass the insertion sort for large subsets of the data. If no one has a strong love for qsort, I'll educate myself on how to make and contribute this change. Sounds good to me.. let's fix it. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
Christopher Seiwald writes: The FreeBSD qsort implementation has a rather nasty degenerate case. If you have data that partitions exactly about the median pivot, yet which is unsorted in either partition, you get get treated to an insertion sort. Example: 1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11 qsort picks 10 as the median, does no swaps on its first pass, and so decides to switch to an insertion sort. The idea is that if no swaps occur, the data is likely to be nearly already sorted and a good candidate for insertion sort. This turns out to be a (very) bad idea if you have some unsorted data buried in the middle of a (very) large dataset. The implementation claims to come from Bentley and McIlroy's paper, Engineering a Sort Function, and this is largely true, but the insertion sort optimization(?) isn't in that paper. The GNU qsort.c only does an insertion sort if it is below a certain threshhold in size, and so never attempts such a sort on the whole dataset. (The GNU qsort does a number of other things pooh-poohed in the Bentley paper.) It's a pretty straightforward change to bypass the insertion sort for large subsets of the data. If no one has a strong love for qsort, I'll educate myself on how to make and contribute this change. Sounds good to me.. let's fix it. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Unsafe code in libc in 3.0-RELEASE FreeBSD i386
Dag-Erling Smorgrav writes:
Archie Cobbs [EMAIL PROTECTED] writes:
Igor Gousarov writes:
The source file for setlocale function (/usr/src/lib/libc/locale/setlocale.c)
contains the line which might put libc into infinite loop:
[...]
Please file a PR to make sure that this doesn't "slip through
the cracks"...
It seems to have slipped through the cracks. Good thing I had a
process mark on this message. What do you think of the attached patch
(against -CURRENT)?
I think there's still a possibility of new_categories being overrun,
since there's no bounds checking on i in the do ... while (*locale)
loop. I suggest that a careful audit by somebody who knows this code
(or at least knows what it's supposed to do).
Sorry for the late reply..
I think I understand what that do { } while loop is trying to do.
Basically, LC_ALL can either be a single locale, in which case all
categories should get that locale, or else several locales all
separated by slashes, in which case consecutive categories get
the respective locales.
I've re-written your patch and simplified it a bit. Let me know what
you think (ie, please review).
Thanks,
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Index: setlocale.c
===
RCS file: /home/ncvs/src/lib/libc/locale/setlocale.c,v
retrieving revision 1.23
diff -u -r1.23 setlocale.c
--- setlocale.c 1998/04/29 22:39:56 1.23
+++ setlocale.c 1999/08/17 19:23:31
@@ -105,8 +105,8 @@
int category;
const char *locale;
{
- int i, j, len;
- char *env, *r;
+ int i, j;
+ char *env;
if (category LC_ALL || category = _LC_LAST)
return (NULL);
@@ -150,32 +150,26 @@
(void)strncpy(new_categories[category], locale, ENCODING_LEN);
new_categories[category][ENCODING_LEN] = '\0';
} else {
- if ((r = strchr(locale, '/')) == NULL) {
- for (i = 1; i _LC_LAST; ++i) {
- (void)strncpy(new_categories[i], locale, ENCODING_LEN);
- new_categories[i][ENCODING_LEN] = '\0';
- }
- } else {
- for (i = 1; r[1] == '/'; ++r);
- if (!r[1])
- return (NULL); /* Hmm, just slashes... */
- do {
- len = r - locale ENCODING_LEN ? ENCODING_LEN : r -
locale;
- (void)strncpy(new_categories[i], locale, len);
- new_categories[i][len] = '\0';
- i++;
- locale = r;
- while (*locale == '/')
- ++locale;
- while (*++r *r != '/');
- } while (*locale);
- while (i _LC_LAST)
- (void)strcpy(new_categories[i],
- new_categories[i-1]);
+ char *s, buf[(_LC_LAST - 1) * (ENCODING_LEN + 1)];
+
+ /* Parse out setting(s) separated by slashes */
+ buf[sizeof(buf) - 1] = '\0';
+ (void)strncpy(buf, locale, sizeof(buf));
+ if (buf[sizeof(buf) - 1] != '\0')
+ return (NULL); /* arg(s) too long */
+ for (i = 1, s = strtok(buf, "/");
+ i _LC_LAST s != NULL;
+ ++i, s = strtok(NULL, "/")) {
+ (void)strncpy(new_categories[i], s, ENCODING_LEN);
+ new_categories[i][ENCODING_LEN] = '\0';
}
+
+ /* Copy last setting for all remaining categories */
+ for (; i _LC_LAST; i++)
+ (void)strcpy(new_categories[i], new_categories[i - 1]);
}
- if (category)
+ if (category != LC_ALL)
return (loadlocale(category));
for (i = 1; i _LC_LAST; ++i) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Unsafe code in libc in 3.0-RELEASE FreeBSD i386
Dag-Erling Smorgrav writes:
Archie Cobbs arc...@whistle.com writes:
Igor Gousarov writes:
The source file for setlocale function
(/usr/src/lib/libc/locale/setlocale.c)
contains the line which might put libc into infinite loop:
[...]
Please file a PR to make sure that this doesn't slip through
the cracks...
It seems to have slipped through the cracks. Good thing I had a
process mark on this message. What do you think of the attached patch
(against -CURRENT)?
I think there's still a possibility of new_categories being overrun,
since there's no bounds checking on i in the do ... while (*locale)
loop. I suggest that a careful audit by somebody who knows this code
(or at least knows what it's supposed to do).
Sorry for the late reply..
I think I understand what that do { } while loop is trying to do.
Basically, LC_ALL can either be a single locale, in which case all
categories should get that locale, or else several locales all
separated by slashes, in which case consecutive categories get
the respective locales.
I've re-written your patch and simplified it a bit. Let me know what
you think (ie, please review).
Thanks,
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Index: setlocale.c
===
RCS file: /home/ncvs/src/lib/libc/locale/setlocale.c,v
retrieving revision 1.23
diff -u -r1.23 setlocale.c
--- setlocale.c 1998/04/29 22:39:56 1.23
+++ setlocale.c 1999/08/17 19:23:31
@@ -105,8 +105,8 @@
int category;
const char *locale;
{
- int i, j, len;
- char *env, *r;
+ int i, j;
+ char *env;
if (category LC_ALL || category = _LC_LAST)
return (NULL);
@@ -150,32 +150,26 @@
(void)strncpy(new_categories[category], locale, ENCODING_LEN);
new_categories[category][ENCODING_LEN] = '\0';
} else {
- if ((r = strchr(locale, '/')) == NULL) {
- for (i = 1; i _LC_LAST; ++i) {
- (void)strncpy(new_categories[i], locale,
ENCODING_LEN);
- new_categories[i][ENCODING_LEN] = '\0';
- }
- } else {
- for (i = 1; r[1] == '/'; ++r);
- if (!r[1])
- return (NULL); /* Hmm, just slashes... */
- do {
- len = r - locale ENCODING_LEN ? ENCODING_LEN
: r - locale;
- (void)strncpy(new_categories[i], locale, len);
- new_categories[i][len] = '\0';
- i++;
- locale = r;
- while (*locale == '/')
- ++locale;
- while (*++r *r != '/');
- } while (*locale);
- while (i _LC_LAST)
- (void)strcpy(new_categories[i],
- new_categories[i-1]);
+ char *s, buf[(_LC_LAST - 1) * (ENCODING_LEN + 1)];
+
+ /* Parse out setting(s) separated by slashes */
+ buf[sizeof(buf) - 1] = '\0';
+ (void)strncpy(buf, locale, sizeof(buf));
+ if (buf[sizeof(buf) - 1] != '\0')
+ return (NULL); /* arg(s) too long */
+ for (i = 1, s = strtok(buf, /);
+ i _LC_LAST s != NULL;
+ ++i, s = strtok(NULL, /)) {
+ (void)strncpy(new_categories[i], s, ENCODING_LEN);
+ new_categories[i][ENCODING_LEN] = '\0';
}
+
+ /* Copy last setting for all remaining categories */
+ for (; i _LC_LAST; i++)
+ (void)strcpy(new_categories[i], new_categories[i - 1]);
}
- if (category)
+ if (category != LC_ALL)
return (loadlocale(category));
for (i = 1; i _LC_LAST; ++i) {
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: host byte order in networkin routines?!?
David E. Cross writes: A friend writing some portable network tunneling software ran into an interesting thing... when you specify IP_HDRINCL with SOCK_RAW, and IPPROTO_RAW you need to construct the outgoing packet in host byte order. This seems wonderfully inconsistent with all of the other socket based networking interface in FreeBSD, and it is also inconsistent with other Operating Systems. Would it be possible to get this changed? I can provide diffs if need be. I suspect most people agree it needs to be changed, but the problem is (as usual) all the legacy code that would break. Maybe if you had a temporary check in the kernel for backwards packets that would cause a core dump.. ? Ugh. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No MAXUID ?
Mike Smith writes: v2 NFS doesn't support UIDs 65535, and UIDs around that number are magic to it as well. There are serious security issues here (files will appear to be owned by the wrong user). Hmm, isn't this a separate bug in itself (unrelated to pwd_mkdb)? Ie, somewhere in the kernel there should be a check for UID wrap that generates an error if detected. At least on the server; on the client of course it would be too late. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: tee option on ipfw?
Jaye Mathisen writes: The man page says the tee option on ipfw is not yet supported. I'm wondering if that is still the case as of 3.2-stable, or if the doc is just out of date. You are correct, it's still not implemented.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: tee option on ipfw?
Jaye Mathisen writes: The man page says the tee option on ipfw is not yet supported. I'm wondering if that is still the case as of 3.2-stable, or if the doc is just out of date. You are correct, it's still not implemented.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Matthew Dillon writes: : ram and 512MB of swap (4MB of swap in use), but the kernel reports over : 3 GB of VM assigned to processes. That's a fairly lightly loaded machine. : :What you say is generally true; however, the problem is that *you* :are making implicit assumptions about what applications *I* might :have in mind. I just think that's a presumptous thing to do unless :you can read minds.. : :For example: : :- I could be creating a "Java OS" that is going to have a single process, : ie, the Java VM, that can handle ENOMEM (which translates into an : OutOfMemoryException, which can be caught) but otherwise *must not die*. just one process? Set a resource limit! If you have 64MB of swap, then limit the size of the Java OS process to 50MB.Now the java process will get a nice malloc failure instead of getting killed by the kernel. That would work too I suppose.. but the larger point is that, who knows what strange/crazy things people might want to do? (Maybe somebody just wants to try it for some kind of empirical test?) Aside from all the hype on either side, the fact that there is even an argument about it means that some people would like to at least have the ability to turn off overcommit. So if it's not a problem to add the sysctl, why not do it? Let them shoot their feet off if that's what will happen. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Jon Ribbens writes: Because memory (as in *real* memory, either RAM or swap) is allocated on-demand. So you can allocate any amount of virtual memory that the system can possibly provide you, even though you'll run out of memory much earlier, because other resources are also consuming it. Yuck. That's a complete abomination. What's the point of it? It's turning an out-of-memory situation from an easily-detected recoverable temporary resource shortage which can be worked-around or waited out, into an unrecoverable fatal error. Do a significant number of programs really request memory which they then proceed not to use? See the various threads from years past regarding the overcommit debate. In short, it depends on your application(s) which is better.. By the way, is there a sysctl that controls this behavior now? There was talk of adding it before.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
How hard would it be to add a sysctl variable that controlled whether or not the system would overcommit memory? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Matthew Dillon writes: :How hard would it be to add a sysctl variable that controlled whether or not :the system would overcommit memory? Archie, the question is barely worth answering. Nobody advocating this stuff has even begun to think-out the ramifications. Adding such a knob would be easy - except it might as well be a crash me now knob when the system starts refusing programs reasonable requests for memory! I mean, jeeze, the reservation for the program stack alone would eat up all your available swap space! What is a reasonable stack size? The system defaults to 8MB. Do we rewrite every program to specify its own stack size? How do we account for architectural differences? * stack * MAP_PRIVATE mmaps * fork (used to fork, not the 'easy' fork/exec case) It adds up pretty quickly. My home server runs smoothly with 128MB of ram and 512MB of swap (4MB of swap in use), but the kernel reports over 3 GB of VM assigned to processes. That's a fairly lightly loaded machine. What you say is generally true; however, the problem is that *you* are making implicit assumptions about what applications *I* might have in mind. I just think that's a presumptous thing to do unless you can read minds.. For example: - I might be creating a very limited embedded system with just a few small processes that are all written to *handle* out of memory situations. - I could be creating a Java OS that is going to have a single process, ie, the Java VM, that can handle ENOMEM (which translates into an OutOfMemoryException, which can be caught) but otherwise *must not die*. In types of situations like this (someone can probably think of more/better examples) overcommit may very well be undesireable. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Matthew Dillon writes: : ram and 512MB of swap (4MB of swap in use), but the kernel reports over : 3 GB of VM assigned to processes. That's a fairly lightly loaded machine. : :What you say is generally true; however, the problem is that *you* :are making implicit assumptions about what applications *I* might :have in mind. I just think that's a presumptous thing to do unless :you can read minds.. : :For example: : :- I could be creating a Java OS that is going to have a single process, : ie, the Java VM, that can handle ENOMEM (which translates into an : OutOfMemoryException, which can be caught) but otherwise *must not die*. just one process? Set a resource limit! If you have 64MB of swap, then limit the size of the Java OS process to 50MB.Now the java process will get a nice malloc failure instead of getting killed by the kernel. That would work too I suppose.. but the larger point is that, who knows what strange/crazy things people might want to do? (Maybe somebody just wants to try it for some kind of empirical test?) Aside from all the hype on either side, the fact that there is even an argument about it means that some people would like to at least have the ability to turn off overcommit. So if it's not a problem to add the sysctl, why not do it? Let them shoot their feet off if that's what will happen. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Repalcement for grep(1)
Jamie Howard writes: Perhaps this will help with -w? Yes, I received a patch from Simon Burge which implements this. It also beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. I am still having trouble with -x though. It turns out that even if I specify a commandline with a pattern of the form "^pattern$", it fails. If I specify "^pattern" it works. If I specify "pattern$" it does not. I have yet to find a case where my version will sucessfully match when a $ is at the end. Has anyone encountered anything like this before? Are you sure you're stripping out the newline and carriage return? -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repalcement for grep(1)
Jamie Howard writes: Perhaps this will help with -w? Yes, I received a patch from Simon Burge which implements this. It also beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. I am still having trouble with -x though. It turns out that even if I specify a commandline with a pattern of the form ^pattern$, it fails. If I specify ^pattern it works. If I specify pattern$ it does not. I have yet to find a case where my version will sucessfully match when a $ is at the end. Has anyone encountered anything like this before? Are you sure you're stripping out the newline and carriage return? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() vs select()
Christopher Sedore writes: Actually.. select() has three copyins and three copyouts per call. poll() has one copyin and one copyout per call. Now what I particular like is the event queue system that David Filo put together for Yahoo. In a nutshell you create a queue (a fd), and then register the descriptors you want to monitor with the queue. You then run an accept()-like loop where the accept returns the fd number that has met the conditions you asked for. For example, if you wanted to know if fd number 4251 becomes readable, then the accept would return 4251. This has potential to work across multiple processes sharing a queue so that events could get round robined or whatever. The other good part is that it maintains the state and lists persistantly and doesn't have to keep copying it to/from the kernel. It handles 50,000 to 100,000 connections without too much trouble. You can still use this with select as the queue fd becomes readable when there is an event waiting for your process. Is there interest in doing something like this in general? You can do much the same thing by using aio functions. I do this now with an added syscall aio_waitcomplete, which allows a process to sleep waiting for the next aio operation to finish. If more work was done on the aio routines to improve their performance (the existing ones are better than select() when you exceed about 40 descriptors), they would be faster than poll or select, and could function in a similar fashion to the event queue scheme above. I've only had about 140 or so connections open in my experiments, but aio has no trouble with these, to the point where my switched 100Mb line is the bottleneck. I experiment more with NNTP than HTTP, though I have toyed with the idea of hacking an existing web server to use aio. I like the event queue idea, but I'd like it for aio completions rather than an enhanced select() function. A new, faster event notification system would be great. But don't forget to include *all* events, not just file descriptor readability/writability. I.e., signal delivery, child exit notification, maybe even support for an arbitrary number of (independent) timers. And make the events independent from each other -- to avoid problems like when an application completely hangs for 90 seconds when it calls gethostbyname(). rant I've seen a zillion programs that have had to manually solve the problems caused by UNIX's lack of a unified event notification system. Eg., ppp(8) has its own timer library, etc. See also bind's event library. What a shameful waste/duplication of effort.. Really the underlying problem is that UNIX (originally) did not have any lightweight threads and options for IPC were (and still are) limited. This is one of the reasons I prefer programming in Java, even if it's slower. /rant -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Porting LILO to FreeBSD
Warner Losh writes: In message 199907031912.maa01...@dingo.cdrom.com Mike Smith writes: : Neither; he'll have to tell the BIOS that the drive's not there. That's what he's doing right now... He doesn't want to keep doing this since it is such a PITA. However, other posters in the thread gave me enough hints that I think that I can help him make it work. LILO's trick of installing a small translating shim on INT 13 may be just the ticket... Long ago I was a Linux hacker before converting to FreeBSD. I thought LILO was great and beat the heck out of FreeBSD's booteasy... -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Repalcement for grep(1)
Jamie Howard writes: Now, I am having a problem though. I cannot figure out how to implement -w and -x. For -x, I tried modifying the regular expression (foo) into ^(foo)$ before compiling, but that did not work. I intended to do something similar with -w. Anyway, I am probably missing the obvious, but does anyone have any ideas regarding how I should implement -w and -x?
