Re: alpha kernel build failure (w/patch)
Steve Price writes:
> }
> +#ifdef __i386__
> sc->wb_btag = I386_BUS_SPACE_IO;
> +#endif
> +#ifdef __alpha__
> + sc->wb_btag = ALPHA_BUS_SPACE_IO;
> +#endif
> #else
> if (!(command & PCIM_CMD_MEMEN)) {
Just a minor comment.. anytime you have something like this, it's
always nice to do it this way instead:
#if defined(__i386__)
sc->wb_btag = I386_BUS_SPACE_IO;
#elif defined(__alpha__)
sc->wb_btag = ALPHA_BUS_SPACE_IO;
#else
#error Machine architecture unsupported
#endif
That way when somebody wants to add M68K support or whatever they
are alerted that they need to implement the new flag at compile
time instead of at panic time :-)
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Panic plus advice needed
Greg Lehey writes: > > * if you still have exactly the same source tree and config file, > > recompile the kernel with -g to obtain the version with debugging symbols > > bde has reported that the code may not be identical when compiling for > debugging. It should be, but for obscure reasons it doesn't quite > make it. I'd be interested in seeing a pointer to those reasons, if you have one.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic plus advice needed
David Malone writes: > > > bde has reported that the code may not be identical when compiling for > > > debugging. It should be, but for obscure reasons it doesn't quite > > > make it. > > > > I'd be interested in seeing a pointer to those reasons, if you have one.. > > One reason adding -g doesn't work at times is if the kernel is > recompiled by a person with a different length username. vers.c > is produced with a string which is a different length which screws > up the offsets. > > Maybe newvers.sh should pad usernames to the legal max? Maybe we should > warn people to touch vers.c after editing the Makefile? That would be really helpful to us actually and I imagine lots of people. In fact, you don't need to pad the username, just add the right number of zeroes to the end of the string, eg. const char *uname = "..blah username blah.." "\0\0\0\0\0"; -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic plus advice needed
Archie Cobbs writes:
> > One reason adding -g doesn't work at times is if the kernel is
> > recompiled by a person with a different length username. vers.c
> > is produced with a string which is a different length which screws
> > up the offsets.
> >
> > Maybe newvers.sh should pad usernames to the legal max? Maybe we should
> > warn people to touch vers.c after editing the Makefile?
>
> That would be really helpful to us actually and I imagine lots of people.
> In fact, you don't need to pad the username, just add the right number of
> zeroes to the end of the string, eg.
Any objections to the patch below?
And a related question: why not define ostype[], et.al. as "const" ?
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Index: newvers.sh
===
RCS file: /home/ncvs/src/sys/conf/newvers.sh,v
retrieving revision 1.42
diff -u -r1.42 newvers.sh
--- newvers.sh 1999/01/21 03:07:33 1.42
+++ newvers.sh 1999/08/03 23:20:32
@@ -34,6 +34,13 @@
# @(#)newvers.sh 8.1 (Berkeley) 4/20/94
# $Id: newvers.sh,v 1.42 1999/01/21 03:07:33 jkh Exp $
+# We use fixed size buffers so that the symbol table will remain the same
+# no matter who does the build. These should be big enough to hold the
+# corresponding strings, plus NUL.
+TYPE_MAXBUF="8"
+RELEASE_MAXBUF="32"
+VERSION_MAXBUF="256"
+
TYPE="FreeBSD"
REVISION="4.0"
BRANCH="CURRENT"
@@ -44,6 +51,20 @@
fi
VERSION="${TYPE} ${RELEASE}"
+# Check for overflow of fixed size string buffers
+if [ ${#TYPE} -ge ${TYPE_MAXBUF} ]; then
+ echo "Error: increase TYPE_MAXBUF"
+ exit 1
+fi
+if [ ${#RELEASE} -ge ${RELEASE_MAXBUF} ]; then
+ echo "Error: increase RELEASE_MAXBUF"
+ exit 1
+fi
+if [ ${#VERSION} -ge ${VERSION_MAXBUF} ]; then
+ echo "Error: increase VERSION_MAXBUF"
+ exit 1
+fi
+
if [ "X${PARAMFILE}" != "X" ]; then
RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
${PARAMFILE})
@@ -91,11 +112,11 @@
touch version
v=`cat version` u=${USER-root} d=`pwd` h=`hostname` t=`date`
echo "$COPYRIGHT" > vers.c
-echo "char ostype[] = \"${TYPE}\";" >> vers.c
-echo "char osrelease[] = \"${RELEASE}\";" >> vers.c
+echo "char ostype[${TYPE_MAXBUF}] = \"${TYPE}\";" >> vers.c
+echo "char osrelease[${RELEASE_MAXBUF}] = \"${RELEASE}\";" >> vers.c
echo "int osreldate = ${RELDATE};" >> vers.c
echo "char sccs[4] = { '@', '(', '#', ')' };" >>vers.c
-echo "char version[] = \
+echo "char version[${VERSION_MAXBUF}] = \
\"${VERSION} #${v}: ${t}\\n${u}@${h}:${d}\\n\";" >>vers.c
echo `expr ${v} + 1` > version
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Panic plus advice needed
Bruce Evans writes: > >Any objections to the patch below? > > Yes. It bloats the kernel and only fixed one cause of the problem. What are the others..? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic plus advice needed
Bruce Evans writes: > >> >Any objections to the patch below? > >> > >> Yes. It bloats the kernel and only fixed one cause of the problem. > > > >What are the others..? > > The only one I can find now is naming the debugging kernel with a name > of different length. This causes different string lengths in config.c > and vers.c. I once thought I saw a problem related to linker sets, but > I was probably mistaken. So... IMHO, if we can fix this as well, it would be worth it for all the people who get core dumps but didn't build debug kernels. Do you disagree? -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic plus advice needed
Peter Jeremy writes: > >>> Yes. It bloats the kernel and only fixed one cause of the problem. > >> > >>What are the others..? > > > >The only one I can find now is naming the debugging kernel with a name > >of different length. > > Also, if your kernel was previously version 9 (or 99 or 999 or ...), > the incremented version number will increase the length of the version > string in vers.c. That's the same thing as we're already talking about (see patch). -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic plus advice needed
Greg Lehey writes: > >> The only one I can find now is naming the debugging kernel with a name > >> of different length. This causes different string lengths in config.c > >> and vers.c. I once thought I saw a problem related to linker sets, but > >> I was probably mistaken. > > > > So... IMHO, if we can fix this as well, it would be worth it for all > > the people who get core dumps but didn't build debug kernels. > > Do you disagree? > > I disagree that this should even be necessary. This kind of detail > was exactly the reason why I put the short-lived default debug kernel > into config. There aren't too many systems any more that don't have > an additional 30 MB for the time it takes to build the kernel, and it > solves a whole lot of potential problems. Sounds OK to me. Was this kernel.debug thing merged into -stable? If not it might be a good thing to do. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dropping connections without RST
Geoff Rehmet writes:
> After the discussions regarding the "log_in_vain"
> sysctls, I was thinking about a feature I would
> like to implement:
>
> Instead of sending a RST (for TCP) or Port Unreachable
> (for UDP) where the box is not listening on a socket,
> I would like to implement a sysctl, which disables the
> sending of the RST or the Port unreachable. This is
> basically for public servers (like DNS servers), which
> I want to turn into black holes on ports where they
> are not listening. (This confuses things if someone
> strobes the machines, and also makes life a little
> more difficult for anyone who tries to portscan them.)
>
> In default configuration, everything would behave as per
> normal, and you would have to set a sysctl MIB before the
> behaviour that I have described is displayed.
>
> Can anyone think of any reason why this feature should
> not be implemented?
I like that idea... net.inet.{tcp,udp}.drop_in_vain ?
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Dropping connections without RST
Brian W. Buchanan writes:
> > > Can anyone think of any reason why this feature should
> > > not be implemented?
> >
> > I like that idea... net.inet.{tcp,udp}.drop_in_vain ?
>
> Why do we need a sysctl knob for this when it can be easily accomplished
> with IPFW?
Not that easily.. how are you going to make ipfw dynamically know
which ports have listeners and which don't?
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Dropping connections without RST
Geoff Rehmet writes: > > : Not that easily.. how are you going to make ipfw dynamically know > > : which ports have listeners and which don't? > > > > By filtering all RST packets? > > My view was that this is much simpler than filtering packets - > never generate the packet. My guess is that it creates lower > overheads. In some instances, I don't want to look at every > packet (which in effect happens with a packet filter). Plus, packets with RST in them are used for other purposes besides rejecting new incoming connections.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
Mike Smith writes: > I will be converting all users of at_shutdown in the kernel to the new > mechanism, but it's of some concern to me that there may be external > code using the old at_shutdown* interfaces that may benefit from a > compatibility interface (which could be done relatively easily). > > Is there significant interest in having this implemented? We (ie, Whistle) has some "external code" that uses at_shutdown but it would be trivial to update it for the new interface, so I say go ahead! This sounds like a good change. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
Matthew Dillon writes: > :On a somewhat similar note, what do you think about converting a lot > :of the NFS macros to functions, yes i know it will be difficult, but > :there is so much forced inlining it just seems like it would reduce > :the codesize signifigantly and play nicer with the CPU cache. > : > :It would also make the code a lot more readable. > : > :Worthwhile exercise? > : > :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > > Well, the issue with converting many of the macros to inline functions > is with the embedded goto's and references to variables defined outside > the macros. Converting them to functions would basically require > rewriting a huge chunk of NFS code. > > This is one of those "If it ain't broke, don't fix it" scenarios, I'm > afraid. It would take too long to redo it all (and remember, I'm the > guy who usually *likes* rewriting code!). As much as I would like to > make NFS more readable, it just isn't worth the effort. It still might be a "worthwhile exercise", if your goal is simply to increase your understanding of the NFS code. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Boot serial console all blanks
Has anyone else seen this problem? The 2nd and 3rd stage boot loader output to the serial port is all blanks. That is, every character is output as a blank -- you can see them printing, and see the 10 second autoboot messages, but they're all space characters. Thanks for any insights. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Boot serial console all blanks
Warner Losh writes: > : The 2nd and 3rd stage boot loader output to the serial port is all > : blanks. That is, every character is output as a blank -- you can > : see them printing, and see the 10 second autoboot messages, but > : they're all space characters. > > I have seen this when I've had the baud rate wrong. On my development > box that has a serial console, I seem to recall that I needed to build > special bootblocks to run at 115200. > > Try connecting a serial line analyser to the line if you have it. Or > a oscope will do in a pinch. Or try the default baud rate of 9600. I am doing 9600 baud.. also, this is a slightly abnormal setup, using the old boot0/boot1 bootblocks (because it's an InterJet) with /kernel hardlinked to 3.4-REL /boot/loader (so I can boot an ELF kernel). The old bootblocks print normally, then /boot/loader prints all spaces, then when the kernel itself boots it prints normally again. Everything seems to be printing at the same baud rate (9600). Maybe the old boot blocks are confusing the loader in the way they are configuring the serial port.. ? -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: flaw in modules system?
Richard Wackerbarth writes: > > When we do a 'make install' on the kernel, it automatically copies > > /kernel to /kernel.old, and copies the new kernel in ... is there no way > > of extending this to the modules? > > > > The one thing I was thinking might be to have it so that if you > > 'load kernel.old' (ie. kernel didn't boot properly, so you have to > > revert), when it loads its modules, it loads .old to go along with > > it... > > > > Basically, the modules are tied to the kernel, so is there any way > > of having them install along with the kernel ... ? > > Peter W. was working on this but it wasn't going to be ready in time for the 4.0 > freeze. Therefore it got put "on hold" until 4.0 gets released. Expect it soon > thereafter. How about solving a simpler problem: have kldload fail if the module is not "compatible" with the currently running kernel. For starters, we could define "compatible" as something simple, eg.: - build date must be the same day - Same OSRELDATE - ?? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
Richard Wackerbarth writes: > There are two problems in the size of the ports system. > 1) The large number of inodes. I don't see the ports tree as the problem. The problem is that FreeBSD does not handle a very large directory hierarchy like that presented by the ports tree very well. The right angle of attack IMHO is to better optimize the kernel and maybe the filesystem. I don't know enough to know how you would do this though. For example, there's the thing about how we don't cache filesystem data and filesystem meta-data (directory blocks) the same way (this is the best I can describe it). > Now, here is a really "silly" idea. Why don't we make a `port` collection of > the FreeBSD kernel and standard userland utilities? That would lead to > the next step of having the "standard distribution" become just a meta package > much like 'kde' pulls in 'kdebase', 'kdeutils', 'kdegraphics', etc. This idea makes a lot of sense. All of FreeBSD could be packagable as ports/packages. It might even simplify the installer. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dummy ethernet interface.
Giorgos Keramidas writes:
> Is there some way to ifconfig up a dummy ethernet interface, one that
> will work like the loopback one (lo0) on FreeBSD?
If you want an interface that loops back, you can have more than
one loopback interface (lo0, lo1, lo2, ...).
If you want an interface that discards everthing, you can create
a netgraph interface ("ngctl mkpeer iface foo inet") and leave it
unconnected.
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: IP tunnel
Cob writes:
> What about ${subj} in current?
> Or maybe someone know how to make
> ip tunnel on current using patches, tools, etc.?
One way is exhibited in /usr/share/examples/netgraph/udp.tunnel.
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" 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-current" 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-current" 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-current" 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-current" 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-current" 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-current" in the body of the message
Re: NETGRAPH (proposal. FINAL)
Julian Elischer writes: > > here is url: http://home.earthlink.net/~evmax/ng.tar.gz > > > > these are final patches for NETGRAPH. > > new features: > > - new hook ``divertin'' allows to put frame back to > > kernel stack. > > - new control message allows to set raw mode on > > ``divert'' hook. raw mode assumes that we have > > fully prepared frame and we do not have to update > > ``ether_shost'' field. > > This is good in theory, however the intel 82586 ethernet chip > (and 596 in 586 mode) will overwrite anything you put there anyhow > as it treats the header specially and fabricates it. > (unless you are running in some mode that is not usually used). > I don't know how many other chips do this but it may be misleading > for the user who sets this on such a chip because the source > address he sets will not be put on the wire. > > The idea is however useful and I guess we'll try add it in > in the near future... > What do you think Archie? > Are we still in code freeze? (I think so). Yes, I was going to take a look at this after 4.0-REL and then commit something hopefully soon thereafter.. By the way, if the ethernet chip doesn't support manual source address then BPF has the same problem that we do.. IMHO, we should just punt and return an error in this case.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ICMP socket weirdness
Can someone explain the weird behavior I'm seeing from the
program below??
When the program is run, if you ping the IP address from the
local machine, it sees packets. However, if you ping it from
a remote machine, it doesn't see packets.
This is on a 3.4-REL machine.. it also happens on a 4.0-current
machine built on approx Feb. 2.
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
#include
#include
#include
#include
#include
#include
#include
#include
#include
int
main(int ac, char *av[])
{
struct sockaddr_in a;
u_char buf[8192];
int r, s;
memset(&a, 0, sizeof(a));
a.sin_family = AF_INET;
a.sin_len = sizeof(a);
if (ac != 2 || inet_aton(av[1], &a.sin_addr) == 0)
errx(1, "Usage: stest ipaddr");
if ((s = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP)) == -1)
err(1, "socket");
if (bind(s, (struct sockaddr *)&a, sizeof(a)) == -1)
err(1, "bind");
while ((r = read(s, buf, sizeof(buf))) > 0)
printf("Rec'd %d byte packet\n", r);
if (r != 0)
err(1, "read");
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
kern/8324
This bug has been around since at least 2.2.6 and is still present in RELENG_3, RELENG_4, and -current. http://www.freebsd.org/cgi/query-pr.cgi?pr=8324 Is anyone planning to tackle it? What would be required to fix it? (it's not clear (to me anyway) from Bruce's description how hard this is to fix..) Thanks, -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: free vnode isn't
Bob Bishop writes: > >Unfortunatly with this sort of panic, the panic is correct. The actual > >dammage was done some (possibly considerable) time before. So a traceback > >isn't so useful. > > OK, so how do I proceed to get some more useful info? It's still happening. I'd suggest turining off soft-updates first. Then if the panic goes away, at least we have confirmed that soft updates is the likely culprit. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The eventual fate of BLOCK devices.
Jonathan M. Bresler writes: > > Here's the whole story: > > > > - I sent a "which" command from the newsgate account. > > > > - Got a response with about 30 lists to which that account > >is subscribed. > > > > - Compared those lists to the lists that the newsgate > >is prepared to handle (and to which it was once subscribed). > > > > - Noticed that three lists were missing: announce, arch, and > >security-notifications. > > arch and security-notifications do not honor which requests. It sounds like it would be nice then to have majordomo add a note to its response indicating this. Is that possible to configure? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "man" reads /etc/rc.conf?
[EMAIL PROTECTED] writes: > (101) netchild@ttyp2 > man -k adadadad > cat: /etc/isdn/connect.parameters: Permission denied > adadadad: nothing appropriate > > (102) netchild@ttyp2 > grep cat /etc/rc.conf.local > spppconfig_isp0="`cat /etc/isdn/connect.parameters`" > > Is this just my system or is man really reading rc.conf(.local)? ktrace(1) would tell for sure.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
Andrzej Bialecki writes: > I'd like to know whether we reached some conclusions concerning the naming > of sysctl variables created (or related to) KLDs. I know that Linux > emulator creates "compat.linux". I don't know if any other module creates > sysctls (well, except my SPY module.. :-). > > So, what is the current thinking? Should we use > > modules.my_module.whatever, or > > kld.my_kld.whatever, or > > just sprinkle the new sysctls randomly over the tree, according to their > functions, e.g. > > kern.my_module_kern_hook > net.inet.my_module_inet_hook > ... I think the latter. In 'theory' there should be no discernable difference between functionality from a KLD vs. the same functionality compiled directly into the kernel. KLD's are just a linking mechanism, and shouldn't have any more significance than that from a usability perspective. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
Andrzej Bialecki writes: > > KLD's are just a linking mechanism, and shouldn't have any more > > significance than that from a usability perspective. > > Hah. If it were so simple... > > Let's take the example of a module foo, which provides unique features of > bar and baz. They are unrelated to any already existing category. Where > they should be hooked up? kernel? machdep? Then these categories will > become a messy, amorphic trashcans. Also, it will be difficult to see > which sysctls will disappear when the module is unloaded. Well, IMHO the problem of how to organize the sysctl tree is orthogonal (ie, completely independent) from how the kernel is linked. I guess if you imagine a world where hundreds of third party vendors are distributing KLD's that do all kinds of crazy things, then yes perhaps we need a "miscellaneous" category eg, misc.foo.bar .. But right now it looks like 99% of KLD's are part of FreeBSD itself. So there's no reason we can't put them in their correct sysctl location right from the beginning. > More or less, my question is: how the sysctl tree will look like when > _most_ of the kernel will be in modules? Just like it does now. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
Jordan K. Hubbard writes: > > I think the latter. In 'theory' there should be no discernable > > difference between functionality from a KLD vs. the same functionality > > compiled directly into the kernel. > > Only in theory, of course. :) > > As Andrzej has already pointed out, modules can also be loaded and > unloaded, creating a sysctl space where things enter and leave > dynamically. Let's say I'm somebody who creates a nifty little GUI > sysctl editor for the CLI-challenged and, because it's time-consuming > to build a form with fields for all the relevant sysctl variables, I > take the obvious shortcut of parsing the output of `sysctl -A' once at > startup time and then dealing with the individual field callbacks > thereafter. On my "classic" system with a config-generated kernel, > this works just fine and my GUI front-end for sysctl is eventually > declared "useful enough" that I start handing it around. Then > somebody who actually loads and unloads klds tries to use it, and > results (needless to say) are no longer quite in alignment with > expectations. :) Just a hypothetical scenario, of course, but > I simply wanted to make the point that "no discernable difference" > might be hard to achieve for certain values of discernment. I think sysctl nodes appearing and disappearing falls into the same category as /dev files appearing and disappearing -- it's a natural thing to do in this day of dynamic devices, etc. but some programs were written with an implicit assumption that that would never happen. In other words, it's not a problem specific to KLD's .. but it's still a problem :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/8324
Don Lewis writes:
> } * Archie Cobbs <[EMAIL PROTECTED]> [000317 17:55] wrote:
> } > This bug has been around since at least 2.2.6 and is still present
> } > in RELENG_3, RELENG_4, and -current.
> } >
> } > http://www.freebsd.org/cgi/query-pr.cgi?pr=8324
> } >
> } > Is anyone planning to tackle it? What would be required to fix it?
> } > (it's not clear (to me anyway) from Bruce's description how hard
> } > this is to fix..)
>
> I never heard of using SIGIO for output, but section 6.4 of the daemon
> book says that SIGIO is sent "when a read or write becomes possible".
> On the other hand, section 10.8 (Terminal Operations) mentions SIGIO
> for input but not for output. I also looked at rev 1.1 of kern/tty.c
> and it only sends a SIGIO when input is ready, so this seems to be
> the historical behaviour, so I'm suprised that this program even
> worked with plain tty devices.
>
> } I think Bruce sort of went off into a tangent with his diagnosis,
> } anyhow this is untested (of course :) ), but looks like the right
> } thing to do (from sys_pipe.c).
> }
> } Perhaps the fcntls and ioctls aren't being propogated enough to set
> } the flags properly, but if they are then it should work sort of the
> } way SIGIO does, basically generating a signal for /some condition/
> } on a descriptor.
>
> This patch (vs the 3.4-STABLE version of tty.c) causes SIGIO to be
> sent when a regular or pseudo tty becomes writeable.
>
>
> --- tty.c.origSun Aug 29 09:26:09 1999
> +++ tty.c Sat Mar 18 03:09:32 2000
> @@ -2133,6 +2133,8 @@
>
> if (tp->t_wsel.si_pid != 0 && tp->t_outq.c_cc <= tp->t_olowat)
> selwakeup(&tp->t_wsel);
> + if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL)
> + pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL));
> if (ISSET(tp->t_state, TS_BUSY | TS_SO_OCOMPLETE) ==
> TS_SO_OCOMPLETE && tp->t_outq.c_cc == 0) {
> CLR(tp->t_state, TS_SO_OCOMPLETE);
>
>
> BTW, I had to add:
> fcntl(1, F_SETOWN, getpid());
> to the test program since there is no longer a default target to send
> the signal to. The old scheme had the defect of sending SIGIO to the
> process group that owned the terminal, which implied that the terminal
> had to be the controlling terminal for the process group. This limited
> a process to only receiving SIGIO from one terminal device even if it
> had more than one open and it wanted to receive SIGIO from all of them.
> Also, SIGIO was sent to the entire process group, but it may be desireable
> to limit this to one process. I wonder if it might make sense to go
> back to the old default for tty devices so that processes only receive
> SIGIO when they are in the foreground ...
Don-
After applying your patch to kern/tty.c and adding the F_SETOWN,
the problem indeed seems to go away..
Is this patch ready to be committed, or do we need more reviewers?
Thanks,
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ICMP socket weirdness
Garrett Wollman writes: > > When the program is run, if you ping the IP address from the > > local machine, it sees packets. However, if you ping it from > > a remote machine, it doesn't see packets. > > The ICMP never passes certain packets up to raw listeners. These > include ECHO REQUEST, TIMESTAMP REQUEST, and SUBNET MASK REQUEST > packets -- but not the corresponding replies! So, when you ping the > local machine, you will see the ECHO REPLY packets on all raw > listners, but not the initial ECHO REQUESTs. When you ping from a > remote machine, you never see the ECHO REQUEST packets because the > kernel takes care of them, and you never see the ECHO REPLY packets > because they are addressed to the other machine. Is this a FreeBSD-specific thing, or to other UNIX's have this same peculiar behavior? > It would be possible to pass all ICMP packets to the raw listeners, > but it would require rewriting parts of icmp_input() (which would not > be a bad idea) either to avoid modifying the packet in-place or to > keep a copy of the original before responding -- either of which would > slow down `ping' processing. The existence of m_dup() makes the latter option a lot easier.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ssh to freefall broken
Just updated to -current.. previously, when ssh'ing to freefall, no password was required at all -- it just worked. Now I get this: $ ssh [EMAIL PROTECTED] Warning: Server lies about size of server host key: actual size is 1023 bits vs. announced 1024. Warning: This may be due to an old implementation of ssh. Warning: identity keysize mismatch: actual 1023, announced 1024 Agent admitted failure to authenticate using the key. Authentication agent failed to decrypt challenge. Enter passphrase for RSA key '[EMAIL PROTECTED]': This wouldn't be a big problem except for CVS_RSH=ssh .. meaning every cvs operation requires a password. Any ideas what I'm doing wrong? Thanks, -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
Harold Gutch writes: > > Just updated to -current.. previously, when ssh'ing to freefall, > > no password was required at all -- it just worked. Now I get this: > > > > $ ssh [EMAIL PROTECTED] > > Warning: Server lies about size of server host key: actual size is 1023 bits vs. >announced 1024. > > Warning: This may be due to an old implementation of ssh. > > Warning: identity keysize mismatch: actual 1023, announced 1024 > > Agent admitted failure to authenticate using the key. > > Authentication agent failed to decrypt challenge. > > Enter passphrase for RSA key '[EMAIL PROTECTED]': > > > > This wouldn't be a big problem except for CVS_RSH=ssh .. meaning > > every cvs operation requires a password. > > > > Any ideas what I'm doing wrong? > > You're using OpenSSH - I think removing the approprate entry from > your ~/.ssh/known_hosts, then logging in once and saving the > "new" hostkey fixed that problem. Doesn't work. I removed the 'freefall' key from ~/.ssh/known_hosts and even changed '1024' to '1023' but that didn't help. When I ssh from a 4.0-stable machine, everything works as before. Is anyone else seeing this problem? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
Archie Cobbs writes: > When I ssh from a 4.0-stable machine, everything works as before. ^^ Oops- sorry, that should be a "3.4-RELEASE" machine. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
Kris Kennaway writes: > > $ ssh [EMAIL PROTECTED] > > Warning: Server lies about size of server host key: actual size is 1023 bits vs. >announced 1024. > > Warning: This may be due to an old implementation of ssh. > > Warning: identity keysize mismatch: actual 1023, announced 1024 > > Agent admitted failure to authenticate using the key. > > Authentication agent failed to decrypt challenge. > > Enter passphrase for RSA key '[EMAIL PROTECTED]': > > How long had it been since you updated? OpenSSH changed some defaults a > while back, including defaulting to not do agent forwarding, I > think. Check the config files and add it back if necessary. Hmm.. I set "ForwardAgent yes" in /etc/ssh/ssh_config but that didn't help.. from this verbose output it looks like the line saying "Agent admitted failure to authenticate using the key" is the root of the problem.. Warning: identity keysize mismatch: actual 1023, announced 1024 debug: Trying RSA authentication via agent with '[EMAIL PROTECTED]' debug: Received RSA challenge from server. Agent admitted failure to authenticate using the key. Authentication agent failed to decrypt challenge. debug: Sending response to RSA challenge. debug: Remote: Wrong response to RSA authentication challenge. debug: RSA authentication using agent refused. Maybe there's a problem with ssh-agent? FYI- here's what I'm doing 1. On machine A (3.4-REL): "ssh-agent tcsh" 2. On machine A (3.4-REL): "ssh-add" then enter passcode 3. On machine A (3.4-REL): "ssh " 4. On machine B (5.0-current): enter password on machine B 5. On machine B (5.0-current): "ssh [EMAIL PROTECTED]" If I leave out steps #3 and #4 then it works fine as before. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
Mike Pritchard writes: > > Kris Kennaway writes: > > > > $ ssh [EMAIL PROTECTED] > > > > Warning: Server lies about size of server host key: actual size is 1023 bits >vs. announced 1024. > > > > Warning: This may be due to an old implementation of ssh. > > > > Warning: identity keysize mismatch: actual 1023, announced 1024 > > > > Agent admitted failure to authenticate using the key. > > > > Authentication agent failed to decrypt challenge. > > > > Enter passphrase for RSA key '[EMAIL PROTECTED]': > > Are you still being asked for your passphrase? I noticed a couple > of days ago that ssh to freefall wanted my passphrase, but I didn't need > it yesterday or today. Sunspots? Full moon? Yes, that's what has changed.. before it never asked, now it always asks. For me it's not intermittent.. it's consistent. > Even before OpenSSH, I've had this problem in the past. Sometimes > it seemed to be due to reverse DNS lookups not resolving > correctly (my ISP wasn't always responding to reverse DNS > lookups correctly). That doesn't seem to be the problem.. I can resolve my IP address from freefall (in another window) at the same time it's failing.. This only happens when going from machine A -> machine B -> freefall. Machine A is 3.4-REL, machine B is either 4.0-stable or 5.0-current (as of a couple of days ago). When going directly from machine A -> freefall it works fine... in this case no newer versions of FreeBSD are invovled. Previously, when machine B was 3.4-REL or pre-4.0-current (as of a few months ago), it worked fine. Since then, only 'machine B' has changed. Machine A (and presumably freefall) haven't. It may be something stupid I'm doing.. but if it is, then I was was doing it before and it used to work :-) It also may have to do with the warning 'Server lies about size of server host key: actual size is 1023 bits vs. announced 1024.' A complete trace is included below. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com [machineA] $ ssh -v machineB SSH Version 1.2.26 [i386-unknown-freebsd3.1], protocol version 1.5. Standard version. Does not use RSAREF. machineA.whistle.com: Reading configuration data /usr/local/etc/ssh_config machineA.whistle.com: Applying options for * machineA.whistle.com: ssh_connect: getuid 1000 geteuid 0 anon 0 machineA.whistle.com: Connecting to machineB [207.76.205.132] port 22. machineA.whistle.com: Allocated local port 751. machineA.whistle.com: Connection established. machineA.whistle.com: Remote protocol version 1.5, remote software version OpenSSH-1.2.2 machineA.whistle.com: Waiting for server public key. machineA.whistle.com: Received server public key (768 bits) and host key (1024 bits). machineA.whistle.com: Host 'machineB' is known and matches the host key. machineA.whistle.com: Initializing random; seed file /home/archie/.ssh/random_seed machineA.whistle.com: IDEA not supported, using 3des instead. machineA.whistle.com: Encryption type: 3des machineA.whistle.com: Sent encrypted session key. machineA.whistle.com: Installing crc compensation attack detector. machineA.whistle.com: Received encrypted confirmation. machineA.whistle.com: Connection to authentication agent opened. machineA.whistle.com: Trying RSA authentication via agent with '[EMAIL PROTECTED]' machineA.whistle.com: Server refused our key. machineA.whistle.com: RSA authentication using agent refused. machineA.whistle.com: Trying RSA authentication with key '[EMAIL PROTECTED]' machineA.whistle.com: Server refused our key. machineA.whistle.com: Doing password authentication. archie@machineB's password: machineA.whistle.com: Requesting pty. machineA.whistle.com: Failed to get local xauth data. machineA.whistle.com: Requesting X11 forwarding with authentication spoofing. machineA.whistle.com: Remote: X11 forwarding disabled in server configuration file. Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side. machineA.whistle.com: Requesting authentication agent forwarding. machineA.whistle.com: Requesting shell. machineA.whistle.com: Entering interactive session. Last login: Fri Apr 21 10:32:24 2000 from machineA.whistle.co Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.0-STABLE (MACHINEB) #0: Thu Apr 20 10:53:28 PDT 2000 Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release
Re: ssh to freefall brokenb
Julian Elischer writes: > I presume the public key at freefall matches the public key > at machine-B. Try connecting back in the other direction > so that the 'known machines' settings are tested. Can't do that because of the firewall.. > > This only happens when going from machine A -> machine B -> freefall. > > Machine A is 3.4-REL, machine B is either 4.0-stable or 5.0-current > > (as of a couple of days ago). > > > > When going directly from machine A -> freefall it works fine... > > in this case no newer versions of FreeBSD are invovled. > > > > Previously, when machine B was 3.4-REL or pre-4.0-current (as of a few > > months ago), it worked fine. > > The ssh in machine B is now different.. before it was ssh1 and now it > is openssh. > What happens if you use TELNET to get to machine B? > does the ssh to freefall still misbehave? > (in other words.. what if machine A is not involved?) Aha.. that works! (note: home directory is the same on A or B) [machineA] telnet machineB ... [machineB] $ ssh-agent tcsh [machineB] $ ssh-add Need passphrase for /home/archie/.ssh/identity Enter passphrase for [EMAIL PROTECTED]: Identity added: /home/archie/.ssh/identity ([EMAIL PROTECTED]) [machineB] $ ssh [EMAIL PROTECTED] Warning: Server lies about size of server host key: actual size is 1023 bits vs. announced 1024. Warning: This may be due to an old implementation of ssh. Warning: /home/archie/.ssh/known_hosts, line 4: keysize mismatch for host freefall.freebsd.org: actual 1023 vs. announced 1024. Warning: replace 1024 with 1023 in /home/archie/.ssh/known_hosts, line 4. Last login: Fri Apr 21 10:25:44 2000 from s205m132.whistle ... -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
Kris Kennaway writes: > On Fri, 21 Apr 2000, Archie Cobbs wrote: > > Machine A is 3.4-REL, machine B is either 4.0-stable or 5.0-current > > (as of a couple of days ago). > > Hmm, I've just tried it with ssh-1.2.27 -> openssh-1.2.3 -> freefall, and > it still works. Maybe it's something about 1.2.26..let me know what > happens after the upgrade. I upgraded to ssh-1.2.27 on 'machineA' and the same problem happens. By the way.. machine B was compiled with USA_RESIDENT=YES. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld error: now it's ngctl
Kent Hauser writes: > ===> usr.sbin/ngctl > cc -O -pipe -Wall -c /usr/src/usr.sbin/ngctl/types.c > /usr/src/usr.sbin/ngctl/types.c: In function `TypesCmd': > /usr/src/usr.sbin/ngctl/types.c:86: structure has no member named `type_name' > *** Error code 1 That commit was a couple of weeks ago.. you probably have an old version of /sys/netgraph/ng_message.h installed... can you check it? -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mp
Garrett Wollman writes: > > I've just built a fresh world here; if you use the cvs-crypto from > > internat, it may be broken. I submitted a patch to Mark Murray which > > should fix it, here it is again just in case: > > I still think (and am going on record) that this is a REALLY, REALLY > BAD idea. So.. what's the decision? Is this going to be backed out or not? I'd like to know before doing the next update & make world.. Thanks, -Archie P.S. whatever everyone else decides is fine with me, though personally I'd prefer it was backed out. _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic during boot under current
Brian Somers writes: > Also (Mark sits beside me at work), is there anyone else out there > that actually runs FreeBSD-current under VMWare (irrespective of the > host OS) ? Julian has done that I think.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bug: "device ether" no longer optional
Andrey A. Chernov writes: > Without "device ether" in config file kernel fails to compile and > complains on undefined function ether_ifdetach() in if.c:if_detach() > > Please fix. I'm working on it. Of course, in order to check in the fix, I first need to build a new kernel and test it. But once running the new kernel, I can't check in the fix thanks to the broken ssh. So now I'm now building another kernel with RANDOMDEV, even though that this is the solution was not at all obvious from reading UPDATING. Luckily I happened to have seen -current in the past couple of days. Trying to search -current on the web site for the appropriate keywords yeilded only articles from the years 1997 through 1999, nothing in 2000, and there is no way to sort by date anyway. I'm not trying to emit blame or anything, just pointing out that anything that makes it harder for developers to build & test new kernels and/or ssh changes and fixes into freefall can lead to exponentially increasing problems and/or delays. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bug: "device ether" no longer optional
Warner Losh writes: > : check in the fix thanks to the broken ssh. So now I'm now building > : another kernel with RANDOMDEV, even though that this is the solution > : was not at all obvious from reading UPDATING. > > Patches to UPDATING welcome. Grumping about UPDATING ignored. :-) OK, does this sound correct? diff -u -r1.91 UPDATING --- UPDATING2000/06/29 00:34:54 1.91 +++ UPDATING2000/06/30 17:01:58 @@ -21,6 +21,10 @@ openssh and openssl should not be used to generate keys from this date to the completion of the work. + Alternately, just include 'options RANDOMDEV' in your kernel + and everything will start working again, albeit with reduced + security. + 2622: The license on the softupdates is now a standard 2 clause BSD license. You may need to remove your symbolic links -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPPoE not working
Brian Somers writes: > Archie, it seems people are having problems using PPPoE since your > ng_ether changes. Any suggestions ? Unfortunately I have limited email contact righ tnow.. but a couple of things come to mind.. - Is is possible to get a tcpdump of before and after? One thing I could imagine is that the new ng_ether may behave differently than the old code with respect to overwriting the source Ethernet address (the new code shouldn't unless the driver does). But I don't think there should be any difference. 'tcpdump not ip' should tell. - Regarding the libnetgraph change, this supposedly fixed a bug, so possibly the code in ppp(8) is relying on broken behavior? Where is this code anyway, I don't see a pppoe.c in usr.sbin/ppp.. I can take a look. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPPoE not working
Julian Elischer writes: > > > The code's in ppp/ether.c. > > > > > > I'll see if I can get time to figure out what's wrong, but I can't > > > promise anything this week. I'm too busy (we're having a FreeBSD > > > mini-conference here in the UK at which I'm speaking...). > > > > > I already solved this one, the problem is that the source address is being >overwritten with 0's. > > As a temporary hack, if you go into ng_pppoe.c, and replace the 0's with your >ethernet address, you'll be golden. > > Actually Archie left out code to add IN the source MAC address. > so it wasn;t being overwritten, it was never being set > > I just committed a fix. > let me know the result Julian, Thanks for the fix. However, this seems like the wrong fix to me. I think the right fix would be for ppp(8) to set the source address, rather than always forcing it in ng_ether.c... that way the "lower" hook really is WYSIWYG and applications where other source addresses may want to be used are possible. I thought the semantics of writing to "lower" or "orphans" were to be that the packet gets delivered out the link exactly "as-is", unchanged. Having the correct source address should be optional. Perhaps there could be a control message to set an "add source address" bit. While we're at it, we could also use a control message to get the unique Ethernet address, turn promiscuous mode on/off, and add multicast addresses. What do you guys think? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NETGRAPH changes
Yevmenkin, Maksim N, CSCIO writes: > Does anybody knows when -current NETGRAPH changes > will be back ported to 4.X branch (if they ever will)? Which changes in particular are you asking about? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NETGRAPH changes
Yevmenkin, Maksim N, CSCIO writes: > > Which changes in particular are you asking about? > > the attach/detach ``ng_ether'' nodes I was planning on MFC'ing that soon. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ether_ifattach() change and VMware
Munehiro Matsuda writes: > :: Make all Ethernet drivers attach using ether_ifattach() and detach using > :: ether_ifdetach(). > > After the commit, VMware seems to hang the system at boot time. > The "vmnet" module, that comes with VMware, needs the included patch. OK, I'm CC:'ing the port maintainer.. > Shouldn't we bump version or something, due to the kernel API change? Good idea.. I just did that. > --- vmnet-only/freebsd/vmnet.c.orgFri Jul 14 16:18:50 2000 > +++ vmnet-only/freebsd/vmnet.cFri Jul 14 16:21:51 2000 > @@ -156,9 +156,7 @@ > DLog(Linfo, DEVICE_NAME "%d: Ethernet address: %6D", ifp->if_unit, >sc->iface.arpcom.ac_enaddr, ":"); > > s = splimp(); > - if_attach(ifp); > - ether_ifattach(ifp); > - bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); > + ether_ifattach(ifp, ETHER_BPF_SUPPORTED); > splx(s); > > return 0; -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible NETGRAPH/NG_ETHER bug
Julian Elischer writes: > > i was working on integration of Ethernet TAP driver and NETGRAPH > > and found strange thing. the problem is that NG_ETHER nodes do not > > detach correctly when interface is gone. i was taking a very quick > > look at it, and, it seems to me that we are missing one reference > > to a node. i think it is ng_name_node/ng_unname pair. > > This is quite possible because until recently interfaces could never > be removed. Therefore the act of removing a node was really > just a case of RESETTING the node. It was not removed. Here's some more info that may be helpful. First of all, until yesterday, if you detach an ethernet interface that was using netgraph you'd get a kernel panic (or somesuch) -- it was simply broken. This change will be MFC'd soon but it hasn't yet so we're talking -current only at this point. Now, it all should work as designed... where "as designed" means: 1. Ethernet nodes appear for each Ethernet interface at the first moment when the following conditions *both* become true: (a) ng_ether.ko KLD is loaded (or kernel has options NETGRAPH_ETHER) (b) The interface is attached (e.g., at boot time, or when the PCCARD or USB device is connected). 2. Ethernet nodes disappear when/if the interface is detached (e.g., you pop out your Ethernet PCCARD). 3. Telling an Ethernet node to shutdown (e.g., "ngctl kill fxp0:") simply *resets* the node, i.e., breaks all connections to other nodes. The node does NOT go away until #2 happens. 4. You cannot kldunload ng_ether.ko until all Ethernet nodes are detached (for obvious reasons, considering #1 and #2). If you are seeing other behavior that this using -current sources, please let me know, as there is a BUG. OTOH, if you think the behavior "as designed" is incorrect, let's discuss. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible NETGRAPH/NG_ETHER bug
Yevmenkin, Maksim N, CSCIO writes: > again, here is one of the millions of possible patches that works for me :) > > *** ng_ether.c.old Tue Jul 18 21:17:54 2000 > --- ng_ether.c Tue Jul 18 21:48:46 2000 > *** > *** 293,298 > --- 293,299 > bzero(priv, sizeof(*priv)); > FREE(priv, M_NETGRAPH); > node->private = NULL; > + ng_unname(node);/* remove node name */ > ng_unref(node); /* free node itself */ > } I think that is the right patch. Thanks! -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0 snapshot install problem
x10] (ttl 54, id 39708) : 4510 005e 9b1c 4000 3606 340e d1b4 06e2 E..^..@.6.4. 0010: cf4c cd7c 0015 0400 e736 9987 3f68 203a .L.|.6..?h : 0020: 5018 4470 49a7 3432 3520 4361 6e27 P.DpI...425 Can' 0030: 7420 6275 696c 6420 6461 7461 2063 6f6e t build data con 0040: 6e65 6374 696f 6e3a 2043 6f6e 6e65 6374 nection: Connect 0050: 696f 6e20 7265 6675 7365 642e 0d0a ion refused... Thanks, -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 snapshot install problem
Hajimu UMEMOTO writes:
> archie> I'm having trouble installing the 5.0-2815-CURRENT snapshot.
> archie> The problem seems to be broken behavior in the installer FTP client.
> archie> My firewall requires using passive mode. The installer asks the
> archie> FTP server for passive mode (using PASV), but then it bogusly asks
> archie> for active mode (using the PORT command) immediately afterwards.
> archie> Yes I selected 'passive mode ftp' for the transfer method.
>
> It seems -CURRENT's libftpio.c always set passive flag according to
> environment variable FTP_PASSIVE_MODE. Then, PASV/PORT selection
> obeys only FTP_PASSIVE_MODE and direction of sysinstall is ignored.
> Does this patch fix your problem?
Don't know, because I'd have to create new install floppies first..
But I don't think this patch would fix things.. I don't see any
logical flaw there. ftpPassive() just checks that the toggle is
set to the right value -- it doesn't necessarily do anything.
The only way I can see that PASV would be sent immediately followed
by PORT is due to incorrect logic in the installer (or possibly a
bug in libftpio's parsing of the 227 reply).
-Archie
> Index: lib/libftpio/ftpio.c
> ===
> RCS file: /home/ncvs/src/lib/libftpio/ftpio.c,v
> retrieving revision 1.37
> diff -u -u -r1.37 ftpio.c
> --- lib/libftpio/ftpio.c 2000/07/10 10:00:20 1.37
> +++ lib/libftpio/ftpio.c 2000/08/17 15:40:43
> @@ -550,7 +550,8 @@
> {
> char *cp = getenv("FTP_PASSIVE_MODE");
>
> -ftpPassive(fp, (cp && strncasecmp(cp, "no", 2)));
> + if (cp)
> + ftpPassive(fp, strncasecmp(cp, "no", 2));
> }
>
> static void
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 snapshot install problem
Hajimu UMEMOTO writes:
> > It seems -CURRENT's libftpio.c always set passive flag according to
> > environment variable FTP_PASSIVE_MODE. Then, PASV/PORT selection
> > obeys only FTP_PASSIVE_MODE and direction of sysinstall is ignored.
> > Does this patch fix your problem?
>
> archie> Don't know, because I'd have to create new install floppies first..
>
> archie> But I don't think this patch would fix things.. I don't see any
> archie> logical flaw there. ftpPassive() just checks that the toggle is
> archie> set to the right value -- it doesn't necessarily do anything.
>
> After checking, FTP_PASSIVE_MODE is tested by check_passive() every
> fetGET() call. check_passive() calls ftpPassive(). So,
> ftp->is_passive is resetted.
OK, now I think I see part of the problem.. check out ftpPassive():
/* Unlike binary mode, passive mode is a toggle! :-( */
int
ftpPassive(FILE *fp, int st)
{
FTP_t ftp = fcookie(fp);
int i;
if (ftp->is_passive == st)
return SUCCESS;
switch (ftp->addrtype) {
case AF_INET:
i = cmd(ftp, "PASV");
if (i < 0)
return i;
if (i != FTP_PASSIVE_HAPPY)
return FAILURE;
break;
case AF_INET6:
i = cmd(ftp, "EPSV");
if (i < 0)
return i;
if (i != FTP_EPASSIVE_HAPPY) {
i = cmd(ftp, "LPSV");
if (i < 0)
return i;
if (i != FTP_LPASSIVE_HAPPY)
return FAILURE;
}
break;
}
ftp->is_passive = !ftp->is_passive;
return SUCCESS;
}
This is completely wrong. The comment "passive mode is a toggle"
is incorrect. It's correct when you're talking about ftp(1)'s
"pass" command, but NOT true in the FTP protocol. Therefore
ftpPassive() should not be issuing any PASV command at all; the
sending of the PASV or PORT command (which applies per-transfer)
is handled by ftp_file_op() anyway (so the one sent by ftpPassive()
ends up having no effect anyway).
What must be happening is that sysinstall is actually setting
up an active mode connection, and the PASV is simply the extraneous
one emitted by ftpPassive().
But why is sysinstall going to active mode? I *know* FTP passive
was selected..
In the meantime, I'll fix ftpPassive()..
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 snapshot install problem
Hajimu UMEMOTO writes:
> archie> But why is sysinstall going to active mode? I *know* FTP passive
> archie> was selected..
>
> This is just because ftpPassive() is called from ftpGet().
>
> ftpGet()
> check_passive()
> ftpPassive()
>
> Further more, if FTP_PASSIVE_MODE is not set, check_passive() calls
> ftpPassive(fp, 0).
> First, sysinstall calls ftpPassive() to intend to use PASV. Then,
> ftp->is_passive is reset to 1.
> Next, ftpGet() calls ftpPassive() according to the setting of
> FTP_PASSIVE_MODE. In installer, FTP_PASSIVE_MODE is not set. Then,
> ftp->is_passive is reset to 0 by ftpPassive() toggle.
> So, ftp_file_op() issues PORT.
Yes, now I understand.. you and your patch are exactly right.
A combined patch is below; please review.
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
diff -ur /usr/src/lib/libftpio/ftpio.3 ./ftpio.3
--- /usr/src/lib/libftpio/ftpio.3 Mon Aug 7 14:14:40 2000
+++ ./ftpio.3 Thu Aug 17 14:39:48 2000
@@ -213,8 +213,10 @@
.Tn FTP
connection.
.It Ev FTP_PASSIVE_MODE
-Force the use of passive mode
-.Tn FTP .
+If defined, forces the use of passive mode, unless equal
+to ``NO'' or ``no'' in which case active mode is forced.
+If defined, the setting of this variable always overrides any calls to
+.Fn ftpPassive .
.El
.Sh BUGS
I'm sure you can get this thing's internal state machine confused if
diff -ur /usr/src/lib/libftpio/ftpio.c ./ftpio.c
--- /usr/src/lib/libftpio/ftpio.c Mon Aug 7 14:14:40 2000
+++ ./ftpio.c Thu Aug 17 14:36:10 2000
@@ -327,37 +327,12 @@
return NULL;
}
-/* Unlike binary mode, passive mode is a toggle! :-( */
int
ftpPassive(FILE *fp, int st)
{
FTP_t ftp = fcookie(fp);
-int i;
-if (ftp->is_passive == st)
- return SUCCESS;
-switch (ftp->addrtype) {
-case AF_INET:
- i = cmd(ftp, "PASV");
- if (i < 0)
- return i;
- if (i != FTP_PASSIVE_HAPPY)
- return FAILURE;
- break;
-case AF_INET6:
- i = cmd(ftp, "EPSV");
- if (i < 0)
- return i;
- if (i != FTP_EPASSIVE_HAPPY) {
- i = cmd(ftp, "LPSV");
- if (i < 0)
- return i;
- if (i != FTP_LPASSIVE_HAPPY)
- return FAILURE;
- }
- break;
-}
-ftp->is_passive = !ftp->is_passive;
+ftp->is_passive = !!st;/* normalize "st" to zero or one */
return SUCCESS;
}
@@ -545,12 +520,17 @@
return i;
}
+/*
+ * This function checks whether the FTP_PASSIVE_MODE environment
+ * variable is set, and, if so, enforces the desired mode.
+ */
static void
check_passive(FILE *fp)
{
-char *cp = getenv("FTP_PASSIVE_MODE");
+const char *cp = getenv("FTP_PASSIVE_MODE");
-ftpPassive(fp, (cp && strncasecmp(cp, "no", 2)));
+if (cp != NULL)
+ ftpPassive(fp, strncasecmp(cp, "no", 2));
}
static void
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: LINT doesn't compile
Poul-Henning Kamp writes: > linking kernel > umodem.o: In function `umodem_set_line_coding': > umodem.o(.text+0xe6a): undefined reference to `memcmp' Somebody remind me again why we don't make memcmp(), memset(), and memmove() available in the kernel? Seems silly, especially since we have things like qsort() and srandom() for instance. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT doesn't compile
Garrett Wollman writes: > > Somebody remind me again why we don't make memcmp(), memset(), > > and memmove() available in the kernel? > > To keep the compiler from pessimizing them. Sooo.. does this same problem exist in userland too? If not, why not? If so, why don't we just fix the problem? I.e. there seems to be something broken here, either in the compiler or somewhere else... and perhaps we should fix that instead of avoiding the issue? Not trying to be annoying, just trying to understand.. Thanks, -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People running with LOCALBASE set to something other than /usr/local?
Satoshi - Ports Wraith - Asami writes: > * However, I was wondering if there was anyone who could fix things that > * weren't PREFIX clean who would also find them on a regular > * basis. That's not you. > > I can help you when the new package building cluster (being put > together by Paul Saab at the moment) comes up for service. I'll run > some builds with LOCALBASE and X11BASE set to someplace other than the > default and flag all ports that don't conform. > > I couldn't do that for a while since I didn't have enough computing > power -- the machines were maxed out just squeezing out the weekly > (and sometimes biweekly) set of packages. Random though.. this stuff sounds like a good use for snapshots! I.e., snapshot before "make install" and then figure out what got installed by decoding the snapshot file, or something like that. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: reducing sbsize: lost count, uid = 1001
I don't know if this is related to the problems you guys are looking at, but I have a box that every so often (every couple of months) panics with a "panic: recieve 1" panic. This panic happens when the socket character count is bogus during a recv(2), etc. system call. So several months ago I came up with a patch to try and track this down, and with the patch it panics immediately.. but I couldn't figure out why at the time and haven't pursued it since then. Anyway, for what it's worth, the patch I was using is here: ftp://ftp.whistle.com/pub/archie/misc/sbcheck.patch Some variant of it may be useful for tracking down this problem too. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel hash table implementation?
Is there a generic hash table implementation in the kernel somewhere? If not, is there any interest in creating one? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Proposal to clarify mbuf handling rules
In looking at some of the problems relating to divert, bridging,
etc., it's apparent that lots of code is breaking one of the rules
for handling mbufs: that mbuf data can sometimes be read-only.
Each mbuf may be either a normal mbuf or a cluster mbuf (if the
mbuf flags contains M_EXT). Cluster mbufs point to an entire page
of memory, and this page of memory may be shared by more than one
cluster mbuf (see m_copypacket()). This effectively makes the mbuf
data read-only, because a change to one mbuf affects all of the
mbufs, not just the one you're working on. There have been (and
still are) several FreeBSD bugs because of this subtlety.
A test for an mbuf being "read-only" is:
if ((m->m_flags & M_EXT) != 0 && MEXT_IS_REF(m)) ...
So an implicit rule for handling mbufs is that they should be
treated as read-only unless/until you either check that it's not,
and/or pullup a new (non-cluster) mbuf that covers the data area
that you're going to modify.
However, many routines that take an mbuf parameter assume that the
mbuf given to them is modifiable and proceed to write all over it.
A few examples are: ip_input(), in_arpinput(), tcp_input(),
divert_packt(), etc.
In practice, this is often not a problem because the mbuf is actually
modifiable (because there are no other references to it). But this
is just because we've been lucky. When you throw things like bridging,
dummynet, divert, and netgraph into the mix, not to mention other
site-specific hacks, then these assumptions no longer hold. At the
minimum these assumptions should be clearly commented, but that's
not even the case right now.
Routines that don't change any data, or that only do m_pullup(),
M_PREPEND(), m_adj(), etc. don't have a problem.
So I'd like to propose a mini-project to clarify and fix this problem.
Here is the propsal:
1. All routines that take an mbuf as an argument must not assume
that any mbuf in the chain is modifyable, unless expclicitly
and clearly documented (in the comment at the top of the function)
as doing so.
2. For routines that don't modify data, incorporate liberal use
of the "const" keyword to make this clear. For example, change
struct ip *ip;
ip = mtod(m, struct ip *);
to:
const struct ip *ip;
ip = mtod(m, const struct ip *);
3. For any routines that do need to modify mbuf data, but don't
assume anything about the mbuf, alter those routines to do
an m_pullup() when necessary to make the data are they are
working on modifiable. For example:
struct ip *ip;
/* Pull up IP header */
if (m->m_len < sizeof(*ip) && !(m = m_pullup(m, sizeof(*ip
return;
ip = mtod(m, struct ip *);
#ifdef NEW_CODE_BEING_ADDED
/* Make sure the IP header area is writable */
if ((m->m_flags & M_EXT) != 0 && MEXT_IS_REF(m)) {
/* m_pullup() *always* prepends a fresh, non-cluster mbuf */
if ((m = m_pullup(m, sizeof(struct ip))) == 0)
return;
ip = mtod(m, struct ip *);
}
#endif
/* Modify the header */
ip->ip_len = 123;
...
The only negative is the addition of the NEW_CODE_BEING_ADDED code
in the relevant places. In practice this test will usually fail,
as most mbufs are modifiable, so there should be no noticable
slowdown. However, robustness should improve, especially when
bridging, diverting, etc.
What do people think? If this is generally agreeable I'll try to
work on putting together a patch set for review.
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to clarify mbuf handling rules
David Malone writes: > We were thinking it might be a good idea to have a flag associated > with mbufs which means they are writable, providing the reference > count is 1. Then we can provide a macro for checking writability. > This flag could be set on jumbo ethernet buffers, but not sendfile > buffers (for example). That's a good idea.. I forgot about things like sendfile, where the mbuf is read-only due to other reasons. So we need some kind of flag it seems. That's good -- it makes it even more obvious. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
John Baldwin writes: > > FreeBSD/i386 bootstrap loader, Revision 0.8 > > ([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000) > > /kernel text=0x2432ca zf_read: fill error > > > > elf_loadexec: archsw.readin failed > > Your floppy is bad. Try a different one. Not necessarily. This also happens if you try to boot boot.flp instead of kern.flp. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
Mike Smith writes: > > > > /kernel text=0x2432ca zf_read: fill error > > > > > > > > elf_loadexec: archsw.readin failed > > > > > > Your floppy is bad. Try a different one. > > > > Not necessarily. This also happens if you try to boot boot.flp > > instead of kern.flp. > > Only if you've been silly enough to only put *half* of boot.flp on a > disk. If it's all there, it works just fine. 8) Doesn't matter how silly it is -- I can guarantee you that at least one person has done it :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to clarify mbuf handling rules
[ note: trimming -current from the CC: list ] Bosko Milekic writes: > 1)The mbuf should be marked read-only explicitly with a single > additional M_FLAG. > > #define M_RDONLY0x0x2000 > > 2)The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is > equal to or greater than 2. This is unfortunate because an additional > check would have to be introduced. > > 3)The flag should be removed in _MEXTFREE only if that first > MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), > the new ref_cnt is exactly 1. > > I'm pretty sure that this way, the subsystem will take care of the > read-onlyness itself pretty transparently, so that relevant code can > simply check for the M_RDONLY bit. (2) is questionable. Sounds good. By the way, MEXT_REM_REF() should be defined differently if INVARIANTS is defined so it KASSERT's the reference count is > 0. > As for the protocol routines that rely on the mbuf to be "read-only," > there may be other side-effects besides for this illegal sharing of > multiple-reference ext_bufs that could result from the possibility of > passing these "read-only mbufs" to them. This possibility should be > investigated. Not sure what you mean here.. got an example? > > Cleaning up this sounds like a good plan. It would be worth > > getting Ian and Bosko involved if possible. > > Sure. If I remember correctly, it was Ian who initially brought this > up. This is perhaps a 2-month old issue by now -- I, at the time, was > busy with the referencing stuff as well as the allocator > re-writing/playing around with (which I will have to continue once the > direction of SMP is further cleared up - at least for this part of the > code) - so I did not want to mix apples and oranges. I wonder if Ian has > some code, though. > > I have _some_ modifications regarding this already in my local tree but > have not yet been able to roll over a diff as my monitor is presently > broken (until the end of this week). In any case, how do you propose > coordinating the work? This seems like a fairly straightforward change. > I'm ready to put on hold whatever I'm doing right now in order > to do this, but only if that's okay with you guys - I want to make sure > that no efforts are being duplicated. Let's keep the discussion on freebsd-net. Here's a proposed sequence of steps, at least to get started.. 1. Implement your 1, 2, 3 above: add the flag and adjust the macros 2. Sprinkle code with const's and KASSERT()'s 3. Wait and see what blows up 4. Continue with my proposed changes -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NgSendMsg may return bad token number
Harti Brandt writes: > NgSendMsg returns the bad token number if the debugging level is higher > than 2. It should use the token number from the message structure instead > of the global gMsgId, because that is changed by the ASCII messages sent > in _NgDebugMsg. The following patch fixes the problem for NgSendMsg: Thanks! I've checked in your fix (plus the same fix for NgSendAsciiMsg()) and will MFC in a few days. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: re-entrancy and the IP stack.
Julian Elischer writes: > > i actually suggested one i.e. have explicit pointers > > to metadata area(s) in the pkthdr. I think you forget the > > most fundamental feature which is performance. > > This is way more important than flexibility i think. > > Which is the reason that this problem exists.. > no-one ever thinks that people will want to do things different > to what they want to do at the time they write it.. > > Flexibility is I think much more important than you suggest. > Wouldn't it have made it easier for you if there had been a flexible > method to pass such information available? > The m_aux field sounds right to me. IMHO m_aux is fine for this. It already includes built-in support for 'blind' free'ing -- when you free an mbuf any aux data automatically gets free'd with it, whether you put it there or not. I've been using this for work-related stuff and it works great. As for performance, if there's only one or two m_aux structures associated with an mbuf, then the linear search of the m_aux list is not a big deal. If we start getting tons of m_aux's piling up, *then* we can start worrying about optimization (and there are plenty of options there). -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
differing behavior of connect(2) in -current?
Hi, We're seeing strange behavior of mpd (netgraph-ified ppp daemon) under -current that doesn't occur under -stable. The problem is that when mpd tries to do a connect(2) on a (PF_INET, SOCK_RAW, IPPROTO_GRE), the kernel returns EINPROGRESS instead of succeeding immediately (note: this is a datagram socket so a connect should succeed immediately). The only catch is that the connect(2) is being done in the kernel by a ng_ksocket(4) node instead of via the normal system call. The ng_ksocket(4) calls soconnect() to perform the connect. I've tried reproducing the same problem with userland code but it doesn't seem to happen. So maybe this is a result of the different threading model in the -current kernel? Any ideas appreciated. Thanks, -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in fxp driver
Jonathan Lemon writes: > >Please consider the case where there are two mbuf chains being > >transmitted, which look like this: > > Um. "Not Possible". I thought m_copypacket() of a cluster mbuf would yield exactly this situation (two headers pointing to the same data region). -Arcihe __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
smbus PCI device?
I'm trying to understand this iic/smbus stuff in order to write a driver for some new hardware. The PCI bus shows this device: found-> vendor=0x8086, dev=0x2413, revid=0x02 class=0c-05-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=b, irq=10 map[20]: type 1, range 32, base fe00, size 4 The class/sub-class/programming interface (highlighted above) indicates a SMBus device as specified by PCI 2.2. However, I'm not sure what that is. Adding the "smbus" device and friends to the kernel config doesn't cause this device to be detected. You'd think all I needed to do then would be to add the device ID to a list in the smbus driver somewhere, but I can't find that list. Does "smbus_pci.c" not exist yet? Of course, you can't download the PCI 2.2 spec without being a "member". Am I going down the right path trying to write a driver for this device? Thanks, -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbus PCI device?
Jeroen Ruigrok van der Werven writes: > >found-> vendor=0x8086, dev=0x2413, revid=0x02 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > > > subordinatebus=0secondarybus=0 > > intpin=b, irq=10 > > map[20]: type 1, range 32, base fe00, size 4 > > pciconf -l will probably show the class as 0x0c0500 I guess? Yes. > >The class/sub-class/programming interface (highlighted above) > >indicates a SMBus device as specified by PCI 2.2. > > > >However, I'm not sure what that is. Adding the "smbus" device and > >friends to the kernel config doesn't cause this device to be > >detected. You'd think all I needed to do then would be to add the > >device ID to a list in the smbus driver somewhere, but I can't find > >that list. Does "smbus_pci.c" not exist yet? > > Normally, that would be enough yes. I think you want: > > src/sys/dev/iicbus and src/sys/dev/smbus Those are in, but there is no driver that recognizes the device and vendor ID above. Guess I'll have to write one as soon as I can get the PCI 2.2 spec. Thanks, -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sendmail related changes
Gregory Neil Shapiro writes: > sendmail's version of vacation is completely backwards compatible with the > existing version. It also contains new features and bug fixes that are not > in the current FreeBSD version. This will take care of PR bin/15227. > > 2. Copy cf config building tree into /usr/share/sendmail/cf Yes to all three! For #2, we can maybe go a step further.. the README in that directory is somewhat daunting. For example, we could also copy the /usr/src/etc/sendmail directory into /usr/share/sendmail/cf/freebsd or something like that (maybe with a simpler Makefile) and include a few more example config files besides "freefall.mc" that demonstrate how to configure in various scenarios. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new library: libisc
FYI-
Absent violent rejection, I'd like to add the ISC utility
library to the FreeBSD build. If you're not familiar, check
out the man pages /usr/src/contrib/bind/lib/isc/*.mdoc. There
are several useful utilities in there. The main thing I'm
interested in is the event library, but there is other useful
stuff in there too.
The changes are pretty small so I've included them below for
anyone interested in reviewing them.
Thanks,
-Archie
_______
Archie Cobbs*Packet Design, Inc. *http://www.packetdesign.com
begin 644 libisc.tgz
M'XL(`)F?[SD"`^U7;6_;-A#V5^M7$&V``G.M%RNQ4Z,IXMIQJLUQB\A9.J!`
M($NT3402!9)R8A3Y[SM2DF.OD@ML:X$->F"8Y-V1/-X=[RC''>J))_Q5X\?!
M,LWN\3%J(`GS+RU"G8Y]@E#/ZMG=DZYI=Q&RS)Y]W$!FXR<@Y<)C"#48I>*0
MW,,*X[#QOX,3!_BQC[#PC4@PC(WW[D@GL1^F`=8#PH5V]L^A70]=M"`A[B,C
MY\-?<6,".UW3OO'O>9VU5:K53'#@M\;U#'[
M]IN^U='.SU&[8[WNHA;\GZ+S/9>R[):6BKL?1%,LCJ
M]6VK;Y\VG]>13M@7?38^N,O,C-]YW0/CRW]I_"9H&OLIXYA+2S$O(*GJ\7N\
MD:WP_"3,2*D@(?H"2#S%]T2$@`6].8D#Q?-S@G_'LK$7
MXCB`'/(EV]KW(D56J\E>@->08[(NX?>RQ0%1XP4$_4IU*(M@@;9<8"$20B5Q
M&:>1%X:TV)%0M2%)./:SSJ-L[M=JPPC'*2S1^CM+0"A^NY(RBK)E\E0<+L9B
MR;Q$Z4P3@F6;9`=.O!B'JN-[22&?4$X>+27&,*?A6O42GZ\+C7@4S)5.G&\I
MTBMRRT:-'PUYJ[,`V%[N'U+_NZK^6[T3<[=5..Y:W:S^]\P3N.+`MD_LSD^N
M_Q[S5^3`V;_'_X_B)3H:0Y*'0G>D:>^=Z>ANY%R?P8"2@_7/=A-J3Q.,:^R$%%\G!%ZW9!((@$68Y\\$C^12I&)E#
M=X6]!!KY),GGA'2YA(('HPA'H#,7F,%@3D3L1R`KS[MK*",_F?$+BD`8Q50@
MNL:,D0`C+]Y`Y?1"Q#>P3K2U@C8<3P:7;NNLV79VCYU0)K8%.1=&^R(Y=6>%
M6[`^:M]&A'-0O)TP*JC8)+"+YDR5^4KF2^L:.V9=J<-7"6XM=EA,6?.P2&'>
MPU([IO^.(/Q]1T3Y=B5-H:*^J5X_.P*:=C68VOM!9F_];3]'BYU%B[T7)O9N
MF-A9(-G:<'(QF(Z=R85TT-%7N<$3[#-QIK])RLZ2>#T(@AD$:;[N'FOHQ3X.
MAQ#LU=SKVU)>B#WF!"&62[-*B6INE%0J!>J,T]BOXL&]K&!Q!RY&U3Q>N1]<
M(%'*&>%%N?8CS'$(>HQ'%5S!Z*:41;CZ4"[ET5(JHTD9?0PYJ7Z3^E#U8*?&(G%HHQS
MC;V@G,ZQJ(PU]X"O7"Q&>)XN*W@'(]P]M*>J$U4.%G$#SECI`SRB^C
MY+A)>>1+WN]>6,5B52K.:.JO#AY_QC8#W\=):9S=Q*N*2+N)1>5!;F)90LLX
MMT`?4U;)JCC%+2/R:FM:\06.WD+ETR4[NG\G2^UL13A:P8>:H%!V(RBI"\BT
MZA7AS2&=%"551U,HO#QE&#VL-KJFNS?CL?/YPNTW]2B`;R/8175TNP]:<'BN
MM#%ZQ8US*!H?9^>&L7RE]).OU9SC_N$.!Y/)W<5GX'?*!>X^?G(S@=-=@;?P
MG:/#7'B_/*%WS*`*U-\C-6K4J%&C1HT:-6K4J%&C1HT:-6K4^/?P
))W?=PZ,`*```
`
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PPP over ATM
Brian Smith writes: > >>Are you aware of any efforts to add PPP over ATM or Netgraph > >>support to the current ATM code? > > > >I'm not aware of any activity in the ATM code at all... > > Ok, well if I were to netgraphify the ATM code, would mpd be sufficient > to get PPP over ATM working? (I have a lot of reading up to do, but Mpd can do PPP over any netgraph hook, so unless there's some particular weirdness to the framing of PPP frames over ATM, it should more or less just work... Quoting from ng_ppp(4): These device-independent hooks transmit and receive full PPP frames, which include the PPP protocol, address, control, and information fields, but no checksum or other link-specific fields. -Archie _______ Archie Cobbs*Packet Design, Inc. *http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPP over ATM
Brian Smith writes: > >> Ok, well if I were to netgraphify the ATM code, would mpd be sufficient > >> to get PPP over ATM working? (I have a lot of reading up to do, but > > > >Mpd can do PPP over any netgraph hook, so unless there's some particular > >weirdness to the framing of PPP frames over ATM, it should more or less > >just work... Quoting from ng_ppp(4): > > > >These device-independent hooks transmit and receive full PPP > >frames, which include the PPP protocol, address, control, and > >information fields, but no checksum or other link-specific fields. > > Ok thanks, I am going to be working to add netgraph support to the > ATM code, who would I contact about getting changes committed > once I have the code working? Start by just sending them to freebsd-net.. or better yet just send an URL... so more than one person can review them. -Archie ___ Archie Cobbs*Packet Design, Inc. *http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mergemaster and $FreeBSD$
My machines get their source code from a local CVS mirror of the FreeBSD source tree, which is at /home/cvs/freebsd/src.. we have our own CVSROOT stuff of course. So when stuff is checked out of the freebsd/* repostitories, the $FreeBSD$ tags don't get substituted correctly. This causes mergemaster to list a zillion files as having differences in only this string every upgrade.. even worse, mergemaster in some cases seems to be comparing only the $FreeBSD$ strings and incorrectly concluding that certain files don't need upgrading, when in fact they do. So.. what stuff in /home/cvs/CVSROOT can I change so that sources in freebsd/* get $FreeBSD$ substitution, but other sources get the normal $Id$ substitution? Surely someone has solved this already.. ? Thanks, -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mergemaster and $FreeBSD$
Tony Finch writes: > >So.. what stuff in /home/cvs/CVSROOT can I change so that sources > >in freebsd/* get $FreeBSD$ substitution, but other sources get the > >normal $Id$ substitution? Surely someone has solved this already.. ? > > If you are using the FreeBSD version of CVS (which has been patched to > support this feature) then the magic file is called "options" and > contains: > > tag=FreeBSD=CVSHeader > tagexpand=iFreeBSD Cool, thanks.. but.. what if a file that's not under /home/cvs/freebsd has $FreeBSD$ in it? Eg, /home/cvs/foo/bar.. I don't want it to get substituted.. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
how to mutex'ify a device driver
As a relatively simple exercise in -current kernel programming, I'm planning to mutex'ify the ichsmb(4) device driver (this is a relatively simple driver that currently uses splhigh()). I'd appreciate some feedback if what I'm doing is the right thing. The plan is to give each instance of the device a mutex. This mutex will be grabbed by both the top level code (when programming the chip to do something or reading the results) and the interrupt code (when servicing an interrupt). So far so good.. but what I don't understand is what happens if the interrupt thread has to block on the mutex? It seems like all other devices sharing the same interrupt (and therefore thread) could be indefinitely blocked from servicing their IRQ's. Or is it just assumed that the top half will never hold the mutex for a "long" time? Thanks, -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current on ibm tp a20p?
Christian Carstensen writes:
> > pccard_mem="0xd4000"
> > in /etc/rc.conf. Or even 0xd8000 if that doesn't work.
>
> Peter,
>
> Thanks for your comment. For some reason my notebook needs
> pccard_mem="0xdc000", but with this option set pcmcia support
> works well.
One thing I noticed is that /etc/defaults/pccard.conf says:
# Available memory slots
memory 0xd4000 96k
while /etc/rc.pccard says:
case ${pccard_mem} in
[Dd][Ee][Ff][Aa][Uu][Ll][Tt])
pccardc pccardmem 0xd
Seems like there are two settings for the same "default"..
or am I confusing two different things?
-Archie
______
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Doug Ambrisko writes: > BTW I saw ADDTRON http://www.addtron.com/ has a base station for around > $220 that can do 128 bit encryption, has an antenna and is Web administered. > I haven't used it but it looks interesting. I've started playing with one of these. It seems to have the interesting feature that it stops bridging all traffic after about an hour of operation, requiring a power cycle. Haven't tried upgrading the firmware yet though.. -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
weird cvs update problem
I have a -current system from Dec. 7 on which I'm trying to do
a cvs update in preparation of make world, and am seeing wierd
stuff like this:
> cvs server: Updating crypto/kerberosIV/appl/afsutil
> U crypto/kerberosIV/appl/afsutil/Makefile.in
> U crypto/kerberosIV/appl/afsutil/aklog.c
> U crypto/kerberosIV/appl/afsutil/kstring2key.c
> U crypto/kerberosIV/appl/afsutil/pagsh.c
> cvs server: Updating crypto/kerberosIV/appl/bsd
> U crypto/kerberosIV/appl/bsd/Makefile.in
> U crypto/kerberosIV/appl/bsd/README.login
> U crypto/kerberosIV/appl/bsd/bsd_locl.h
> U crypto/kerberosIV/appl/bsd/encrypt.c
> U crypto/kerberosIV/appl/bsd/forkpty.c
> U crypto/kerberosIV/appl/bsd/kcmd.c
> U crypto/kerberosIV/appl/bsd/klogin.c
> U crypto/kerberosIV/appl/bsd/krcmd.c
> U crypto/kerberosIV/appl/bsd/login.c
> U crypto/kerberosIV/appl/bsd/login_access.c
> U crypto/kerberosIV/appl/bsd/login_fbtab.c
> U crypto/kerberosIV/appl/bsd/osfc2.c
> U crypto/kerberosIV/appl/bsd/pathnames.h_
> U crypto/kerberosIV/appl/bsd/rcmd_util.c
> cvs update: warning: unrecognized response ` If there are any IP options on `sock',
>die.' from cvs server
> cvs update: warning: unrecognized response ` */' from cvs server
> cvs update: warning: unrecognized response `' from cvs server
> cvs update: warning: unrecognized response `void' from cvs server
> cvs update: warning: unrecognized response `ip_options_and_die (int sock, struct
>sockaddr_in *fromp)' from cvs server
> cvs update: warning: unrecognized response `{' from cvs server
> cvs update: warning: unrecognized response `#if defined(IP_OPTIONS) &&
>defined(HAVE_GETSOCKOPT)' from cvs server
> cvs update: warning: unrecognized response ` u_char optbuf[BUFSIZ/3], *cp;' from
>cvs server
> cvs update: warning: unrecognized response ` char lbuf[BUFSIZ], *lp;' from cvs
>server
The file data is somehow getting mixed into the "control stream"
or something. The cvs server is a 5.0-2506-CURRENT machine
that has been working fine for many months (and I don't see the
same problem when cvs updating from other machines).
I notice that "cvs" was updated to version 1.11 on 10/31/00...
Has anyone else seen this, and if so, what's the fix??
Thanks,
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: weird cvs update problem
John Polstra writes: > > > U crypto/kerberosIV/appl/bsd/login_fbtab.c > > > U crypto/kerberosIV/appl/bsd/osfc2.c > > > U crypto/kerberosIV/appl/bsd/pathnames.h_ > > > U crypto/kerberosIV/appl/bsd/rcmd_util.c > > > cvs update: warning: unrecognized response ` If there are any IP options on >`sock', die.' from cvs server > > > cvs update: warning: unrecognized response ` */' from cvs server > [...] > > It sounds like maybe the rcmd_util.c,v RCS file is corrupted on the > CVS server. Just a guess. I haven't seen the problem here. Don't think so.. this happens rather randomly for random files (i.e., more than one). The same file will update correctly on the second try (but then it barfs on another one). It doesn't seem to happen for patched files, only for files that are downloaded whole.. ie, if you blow away an entire directory and then download it again. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: weird cvs update problem
Nate Williams writes: > > > > > U crypto/kerberosIV/appl/bsd/login_fbtab.c > > > > > U crypto/kerberosIV/appl/bsd/osfc2.c > > > > > U crypto/kerberosIV/appl/bsd/pathnames.h_ > > > > > U crypto/kerberosIV/appl/bsd/rcmd_util.c > > > > > cvs update: warning: unrecognized response ` If there are any IP options on >`sock', die.' from cvs server > > > > > cvs update: warning: unrecognized response ` */' from cvs server > > > [...] > > > > > > It sounds like maybe the rcmd_util.c,v RCS file is corrupted on the > > > CVS server. Just a guess. I haven't seen the problem here. > > > > Don't think so.. this happens rather randomly for random files > > (i.e., more than one). The same file will update correctly on the > > second try (but then it barfs on another one). > > > > It doesn't seem to happen for patched files, only for files that > > are downloaded whole.. ie, if you blow away an entire directory > > and then download it again. > > Just a question. Are you using any sort of transport mechanism (besides > rsh) in the middle? I had problems like this when using F-Secure's > Windows client using compression, which blew up. We switched the users > to SecureCRT and the problems went away. Nope.. just using cvs in pserver mode to a server on the same subnet, not encrypted or compressed or anything. Once I actually get all of the -current sources I'll rebuild world and see if the problem still exists. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
proposed small change to .cshrc
I think the patch below (in some form) was agreed upon a while ago but nobody actually committed it.. in any case, are there any objections? This makes it so if root's shell is /bin/tcsh then CTRL-W erases only the previous word instead of the entire line. Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: src/etc/root/dot.cshrc === RCS file: /home/ncvs/src/etc/root/dot.cshrc,v retrieving revision 1.27 diff -u -r1.27 dot.cshrc --- dot.cshrc 2000/05/28 15:09:31 1.27 +++ dot.cshrc 2001/01/09 17:44:00 @@ -27,4 +27,7 @@ set history = 100 set savehist = 100 set mail = (/var/mail/$USER) + if ( `basename $SHELL` == "tcsh" ) then + bindkey ^W backward-delete-word + endif endif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed small change to .cshrc
Matt Dillon writes: > if ( $?tcsh ) then > bindkey "^W" backward-delete-word > bindkey -k up history-search-backward > bindkey -k down history-search-forward > endif Why do you need the 'up' and 'down' ones.. doesn't it already do that without explicit configuration? -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Dag-Erling Smorgrav writes: > Julian Elischer <[EMAIL PROTECTED]> writes: > > > Something is terribly broken with ng_ether at the moment. It lacks a > > > MODULE_VERSION line. > > is this required for something to be a depency? > > Yes. > > > Where is it documented? > > It's not, AFAIK. UTSL (like the rest of us) I don't think Julian is at fault here. At some point in the past, MODULE_VERSION wasn't required. Whoever committed the checkin that made suddenly made MODULE_VERSION required should have added it to all affected files, or at least there should have been a HEADS UP, but I don't recall seeing one. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Dag-Erling Smorgrav writes: > > At some point in the past, MODULE_VERSION wasn't required. Whoever > > committed the checkin that made suddenly made MODULE_VERSION required > > should have added it to all affected files, or at least there should > > have been a HEADS UP, but I don't recall seeing one. > > If I recall correctly, it was Mike, and the commit message was fairly > explicit. It seems like fairly explicit commit message wasn't sufficient then. Whatever.. developers should pay more attention and committers should be more explicit. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Julian Elischer writes: > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? > > I am currently using the standard bridging code and IPFIREWALL (ipfw) with > > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > > few of the computers on my network. > > /usr/share/examples/netgraph > man 4 netgraph > man 4 ng_bridge > (etc.) > also a daemon-news article on how it works. 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-current" in the body of the message
Re: status of bridge code
Rogier R. Mulhuijzen writes: > But from my list of wishes I'd say the first 3 are gone. All that's left is > spanning tree. I'm probably going to need this pretty soon, so once more > I'm asking if anyone is working on it. If not I'll start on it. Do you have references for how to do this? As I understand it, there are special Ethernet addresses that are "for bridges only -- do not forward" that are used to construct the spanning tree, etc. What is the "standard" algorithm used by bridges, etc.? > Also, a quick question for you netgraph guys. Why is it that ng_one2many > send a packet only out of one hook? I can see use for an algorithm that > sends packets from the 'one' hook to all the 'many' hooks (that are up) and > keep the normal behaviour for many to one. Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bw limit in netgraph (Was: status of bridge code)
Rogier R. Mulhuijzen writes: > Quick question for the netgraph guru's. I haven't looked yet, but is there > an explanation of the NG_ macros I see used in the netgraph nodes' code? Yes, but it's not documented :) Actually the daemonnews article does document these somewhat. The main ones are NG_MKMESSAGE() for creating a new control message and NG_MKRESPONSE() for creating a response to a control message; and NG_SEND_DATA() to send a data/meta pair, NG_FREE_DATA() to free one. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Rogier R. Mulhuijzen writes: > >Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes.. > > I don't see how though. Lets say I link only to left, right and left2right. > Now when data enters left it will go to both right and left2right. When > data enters right it goes to left. But when data enters left2right it goes > to right, not left, where I want it. Think of each tee node as a 2x packet doubler, then hook them up like this: --- o --- \ o-- \ o \ o-- \ o \ o-- \ o I.e., only use "left", "right", and "left2right". -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
Jaye Mathisen writes: > It would be kind of cool if when managing a remote system if /kernel > failed to boot, then on the next boot, the loader will fire up > /kernel.old, or a /kernel.somethingorother. > > Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and > have at least some assurance that I'll eventually be able to get back to a > kernel I could use. In case in that discussion it wasn't clear, there *is* a way to do this: see man nextboot. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Automated debug sanity checkers
I was thinking about the DIAGNOSTICS replacement macros and had a random thought... Suppose you're sitting in front of a ddb (or better yet gdb) prompt because your kernel has just crashed due to who knows what reason. What do you do to debug this? You start looking at variables, memory, etc for anything funny going on. For example, several times we've spent hours going through a crash dump to find, for example, that a process was on two queues, or some mbuf was mangled, etc. The thought is that it would be really easy to help automate this process, by doing the following: 1. Define a new kernel option INCLUDE_SANITY_CHECKS (or whatever) 2. When this is defined, all the various FreeBSD kernel submodules (VM, networking, device drivers, etc) would include a function that exhaustively runs sanity checks -- ie, validations that all the assumptions in the code are true -- for that particular submodule. This means checking all queues, flags, whatever. 3. The function is required to only READ memory, not modify it. It can report any inconsistencies, though, obviously. 4. The function is linked into a linker set SANITY_SET(...) or whatever Then by simply calling this function from the debugger you can much more quickly narrow down on the problem (and hopefully fix it before you get tired and go to sleep :-) Moreover, since the function is running post-mortem, it can do very detailed checks that would otherwise take way too long. E.g., check every mbuf, every queue entry, check the filesystem, etc. Basically a "fsck" for the kernel memory. Is this something that people would be motivated enough to make as "official" FreeBSD kernel good housekeeping policy? -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
Archie Cobbs writes: > Jaye Mathisen writes: > > It would be kind of cool if when managing a remote system if /kernel > > failed to boot, then on the next boot, the loader will fire up > > /kernel.old, or a /kernel.somethingorother. > > > > Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and > > have at least some assurance that I'll eventually be able to get back to a > > kernel I could use. > > In case in that discussion it wasn't clear, there *is* a way > to do this: see man nextboot. Oops, sorry.. nextboot of course doesn't work with the new bootblocks.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KLD naming
Doug Rabson writes: > > Might it be a good idea to choose a consistent naming scheme for the > > modules? I'd think so because it would help blind loading at the boot > > prompt. If you choose names it the following format: > > > > type_name > > saver_warp > > saver_daemon > > > > the modules of one type will sort together in a directory listing. This is a > > change that will make FreeBSD more user friendly I think. > > When I first started writing KLD, I had a vague notion that there would be > a simple directory structure under /modules, e.g.: > > /modules > pci/ > ncr.ko > ... > isa/ > if_ed.ko > ... > ... I like this idea (subdirectories) better.. it will last longer :-) Witness the explosion of the ports tree. You should then be able to load a module "isa/if_ed.ko" etc and have it work (no leading slash). In fact, we can implement this (maybe it already works) before coming to a final decision on what the actual layout should be. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KLD naming
Mike Smith writes: > > > When I first started writing KLD, I had a vague notion that there would be > > > a simple directory structure under /modules, e.g.: > > > > > > /modules > > > pci/ > > > ncr.ko > > > ... > > > isa/ > > > if_ed.ko > > > ... > > > ... > > > > I like this idea (subdirectories) better.. it will last longer :-) > > It's a really bad idea, because it requires you to classify things. It > also makes it much harder to administer. In addition, classifications > are bad (witness the need to reorganise the kernel source tree). > > > You should then be able to load a module "isa/if_ed.ko" etc > > and have it work (no leading slash). > > And here is a good example. Why would you want to put if_ed in the > "ISA" category when it can be attached to both the PCI and ISA busses? I don't care how you classify it.. of course the "isa" category is wrong. I was just pointing out that having things in subdirectories is better than having a zillion files piled into a single directory. > are bad (witness the need to reorganise the kernel source tree). Maybe I'm just an optimist.. but if we have already solved (through various incarnations) how to classify the kernel source, then we can pretty much inherit this same classification scheme for the modules. After all, they are all *kernel* modules, right? > A single directory holding module files. Blech :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
