Re: Netgraph and KQUEUE(2)
In message: <[EMAIL PROTECTED]> Julian Elischer <[EMAIL PROTECTED]> writes: : Ok but there cound be netgraph nodes that have no hardware but could be : called into creation by some external event. : e.g. a netgraph hook on a pseudointerface like gif or tun. : (not at present but a possibility I was looking at last week) There's an API that one could expose that would allow these sorts of things to be passed to devd. If it is a true interface, then one can discover that with routing announcements, iirc. I'd personally like to see all things in the kernel in the device tree, but there's some good reasons that this might be a touch too radical. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Netgraph and KQUEUE(2)
On Wed, Nov 06, 2002 at 12:48:07PM -0800, Julian Elischer wrote: > > Ok but there cound be netgraph nodes that have no hardware but could be > called into creation by some external event. > e.g. a netgraph hook on a pseudointerface like gif or tun. > (not at present but a possibility I was looking at last week) ng_gif already exists and is in the tree. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg07500/pgp0.pgp Description: PGP signature
Re: Netgraph and KQUEUE(2)
On Wed, 6 Nov 2002, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Julian Elischer <[EMAIL PROTECTED]> writes: > : > : > : On Wed, 6 Nov 2002, M. Warner Losh wrote: > : > : > : 1) Device driver in Netgraph node. When hardware is > : > :activated new Netgraph node is created and new > : > :kevent sent. devd (or something like devd) listens > : > :for these events and does something (loads firmware, > : > :activates device, etc.) > : > > : > Device drivers are not netgraph nodes. They will have a device_t > : > associated with them, which already sends a message via /dev/devctl to > : > devd. You can do anything you want with the results. There's no need > : > to reinvent the wheel that I'm almost done inventing. There's > : > absolutely no need to bring netgraph into it all, and doing so makes > : > it a less generic implementation. > : > : devices that are netgraph nodes may not have any entry in /dev > : and might only appear in the netgraph namespace.. > : e.g. if_ar.c if_sr.c > > It doesn't matter. *ALL* devices have device_t entries. Recall that > device_t is not dev_t. dev_t appears in /dev/. Hardware devices have > to attach to some bus. That's why devd is done in newbus land rather > than in dev_t land. Ok but there cound be netgraph nodes that have no hardware but could be called into creation by some external event. e.g. a netgraph hook on a pseudointerface like gif or tun. (not at present but a possibility I was looking at last week) > > Warner > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Netgraph and KQUEUE(2)
In message: <[EMAIL PROTECTED]> Julian Elischer <[EMAIL PROTECTED]> writes: : : : On Wed, 6 Nov 2002, M. Warner Losh wrote: : : > : 1) Device driver in Netgraph node. When hardware is : > :activated new Netgraph node is created and new : > :kevent sent. devd (or something like devd) listens : > :for these events and does something (loads firmware, : > :activates device, etc.) : > : > Device drivers are not netgraph nodes. They will have a device_t : > associated with them, which already sends a message via /dev/devctl to : > devd. You can do anything you want with the results. There's no need : > to reinvent the wheel that I'm almost done inventing. There's : > absolutely no need to bring netgraph into it all, and doing so makes : > it a less generic implementation. : : devices that are netgraph nodes may not have any entry in /dev : and might only appear in the netgraph namespace.. : e.g. if_ar.c if_sr.c It doesn't matter. *ALL* devices have device_t entries. Recall that device_t is not dev_t. dev_t appears in /dev/. Hardware devices have to attach to some bus. That's why devd is done in newbus land rather than in dev_t land. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: problems with stf(4) and ipv6_gateway_enable
Hi,
> On Wed, 6 Nov 2002 11:02:28 -0800
> Maxime Henrion <[EMAIL PROTECTED]> said:
mux> Sorry to ask you about this again, but I have no idea what to set as a
mux> prefix for xl0. Does 2002:5143:8351:2 sounds sane? The prefix for xl1
mux> is 2002:5143:8351:1 as you suggested.
Yes.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: problems with stf(4) and ipv6_gateway_enable
Hajimu UMEMOTO wrote: > Hi, > mux> Well, my interface which is connected to the net is xl1. The interface > mux> connected to the local subnet is xl0. If I change rtadvd_interfaces to > mux> xl1, ping6 on the box behind the router gets a no route to host while > mux> the DNS lookup worked before, but I wasn't getting any replies. > > Now, I see your network. > > mux> Maybe I should set a prefix for xl0 too ? I really suck at IPv6 :-). > > Yes, you need to set a prefix to xl0. Rtadvd(8) takes a prefix from > an interface which rtadvd(8) advertises a prefix. > You are confusing about tunnel setup, not IPv6 actually. :-) Sorry to ask you about this again, but I have no idea what to set as a prefix for xl0. Does 2002:5143:8351:2 sounds sane? The prefix for xl1 is 2002:5143:8351:1 as you suggested. Thanks again, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: problems with stf(4) and ipv6_gateway_enable
Hi,
> On Wed, 6 Nov 2002 10:20:30 -0800
> Maxime Henrion <[EMAIL PROTECTED]> said:
mux> Well, my interface which is connected to the net is xl1. The interface
mux> connected to the local subnet is xl0. If I change rtadvd_interfaces to
mux> xl1, ping6 on the box behind the router gets a no route to host while
mux> the DNS lookup worked before, but I wasn't getting any replies.
Now, I see your network.
mux> Maybe I should set a prefix for xl0 too ? I really suck at IPv6 :-).
Yes, you need to set a prefix to xl0. Rtadvd(8) takes a prefix from
an interface which rtadvd(8) advertises a prefix.
You are confusing about tunnel setup, not IPv6 actually. :-)
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: problems with stf(4) and ipv6_gateway_enable
Hajimu UMEMOTO wrote: > Hi, > > > On Wed, 6 Nov 2002 09:25:34 -0800 > > Maxime Henrion <[EMAIL PROTECTED]> said: > > mux> However, it still doesn't seem to work properly. When pinging an IPv6 > mux> host from a box in my local subnet, I'm getting this warning on the box > mux> running rtadvd(8) : > > mux> cannot forward src fe80:0001::0a00:20ff:fef9:8c7a, dst 3ffe:8114:1000::036b, >nxt 58, rcvif xl0, outif stf0 > > I suspect your box which you did ping6 from doesn't configure global > address properly. I read your previous mail again, then found one > more suspicious setting as follows: > > ipv6_prefix_xl1="2002:5143:8351:" > rtadvd_interfaces="xl0" > > You need to advertise the prefix to the configured interface. If your > actuall interface is xl1, please set xl1 to rtadvd_interfaces. Well, my interface which is connected to the net is xl1. The interface connected to the local subnet is xl0. If I change rtadvd_interfaces to xl1, ping6 on the box behind the router gets a no route to host while the DNS lookup worked before, but I wasn't getting any replies. Maybe I should set a prefix for xl0 too ? I really suck at IPv6 :-). Thanks, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: problems with stf(4) and ipv6_gateway_enable
Hi,
> On Wed, 6 Nov 2002 09:25:34 -0800
> Maxime Henrion <[EMAIL PROTECTED]> said:
mux> However, it still doesn't seem to work properly. When pinging an IPv6
mux> host from a box in my local subnet, I'm getting this warning on the box
mux> running rtadvd(8) :
mux> cannot forward src fe80:0001::0a00:20ff:fef9:8c7a, dst 3ffe:8114:1000::036b, nxt
58, rcvif xl0, outif stf0
I suspect your box which you did ping6 from doesn't configure global
address properly. I read your previous mail again, then found one
more suspicious setting as follows:
ipv6_prefix_xl1="2002:5143:8351:"
rtadvd_interfaces="xl0"
You need to advertise the prefix to the configured interface. If your
actuall interface is xl1, please set xl1 to rtadvd_interfaces.
mux> router. Moreover, the boot scripts still display :
mux> IPv4 mapped IPv6 address support=NO
You don't need to worry about this message. It shows that you don't
use mapped address. It is default of 5-CURRENT.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Dial in only works for a while
Andrea Venturoli wrote: > I don't really understand the reason why either the modem or the serial port would >change their setting spontaneously. You are right. They don't. > Let's deal with the serial port: it's initialized at boot time by rc.serial, so a >reboot should have set it up right. > In any case wouldn't "sh /etc/rc.serial" be enough to solve the matter in case for >some reasons it wasn't > properly configured? It all depends on how you want your serial port set. I think it is initially set at 9600. > Besides, stty showed a speed of 57600 bps, so I think it was not the problem. > > The modem: doing an ATI4 shows a speed of 57600 (obviously after issuing cu -s), >while ATI5 shows 9600 and 115200 > respectively for the two stored profiles. But again, now that it is working at this >speed, why should it change? It shouldn't, unless it has been accessed by something else. > Furthermore, I often find that cu will only run once; after that, I get a "line in >use" message, although ps shows no > process using /dev/cuaa0 (there is getty on /dev/ttyd0, but that's also true the >first time I run cu). Is there > anything I can do to solve this without rebooting? Try resetting the modem instead. Try this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html Keep also in mind that by setting the serial port to a speed doesn't necessarily mean setting the modem to that speed also. All modern modems are auto detect so by simply typing anything to it the modem's parameters are auto set. However, I would recommend to lock your serial port AND modem's serial speed to a fixed rate and best one is 115200 (or even higher if you have), specially if you are using your modem's hardware compression. I can't recall the AT commands of your 3Com but I think your modem might have some online help. I think its AT$. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Netgraph and KQUEUE(2)
On Wed, 6 Nov 2002, M. Warner Losh wrote: > : 1) Device driver in Netgraph node. When hardware is > :activated new Netgraph node is created and new > :kevent sent. devd (or something like devd) listens > :for these events and does something (loads firmware, > :activates device, etc.) > > Device drivers are not netgraph nodes. They will have a device_t > associated with them, which already sends a message via /dev/devctl to > devd. You can do anything you want with the results. There's no need > to reinvent the wheel that I'm almost done inventing. There's > absolutely no need to bring netgraph into it all, and doing so makes > it a less generic implementation. devices that are netgraph nodes may not have any entry in /dev and might only appear in the netgraph namespace.. e.g. if_ar.c if_sr.c > > Warner > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: NFS functions does *NOT* check if they really have allocatedany memory
On Wed, 6 Nov 2002, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Archie Cobbs wri > tes: > >Oops, you're right.. sorry for the misinformation. > > > >Sounds like a bug to me (did Iasen file a PR?) > > kern/38872 already exists, and I'm sure there is a much older PR > that also describes this problem. Basically it is hard to fix because > the errors are detected so deep within functions and macros that > were never designed to correctly handle mbuf allocation failures. > > I think the most feasable solution would be to use libmchain or > something like it, but even that is a huge amount of work. The > workaround is of course just setting nmbclusters/nmbufs so high > that they never run out... I don't think that is a proper way go around such bug. Thus when you are DoS-ed how can you know how much mbuf you will need ?:). My problem apeared at the moment I've tried to scan 192.168.0.0/16 with nbtscan. Mbufs were exhausted for about 2-3 second. At that moment there was NFS activity - So server crashed... Ok I won't do that again - but someone else ? And how many parts of the kernel are afected by this problem. Raising nmbclusters/nmbufs at same scan with nbtscan will give my server about 2-3 second more life. That is no good and if someone DoS-es you (local user for example) no nmbclusters/nmbufs raising will save you. Can MGET really wait for memory when M_WAIT flag is used and not to timeouts (I don't know howlong is this timeout, but system crushes at the moment of first NFS operation , thus it should be < 10ms :) ? > Ian > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: problems with stf(4) and ipv6_gateway_enable
Hajimu UMEMOTO wrote: > Hi, > > > On Tue, 5 Nov 2002 17:00:40 -0800 > > Maxime Henrion <[EMAIL PROTECTED]> said: > > mux> ipv6_enable="YES" > mux> ipv6_defaultrouter="2002:c058:6301::" # Use this for 6to4 (RFC 3068) > mux> ipv6_prefix_xl1="2002:5143:8351:" > mux> stf_interface_ipv4addr="81.67.131.81" > > It seems you do configure your box as follows: > >(6to4 router) > | 2002:c058:6301:: > | > | > | stf0 > | 2002:5143:8351:0::1 >(your box) > | xl1 > | 2002:5143:8351:0:EUI-64 > | > --+ > 2002:5143:8351:0::/64 > > You cannot share 2002:5143:8351:0::/64 between xl1 and stf0. Please > don't use same SLA-ID for xl1 and stf0. If you want to use 0 for stf0 > (default of stf_interface_ipv6_slaid), please use non-zero SLA-ID for > xl1 like: > > ipv6_prefix_xl1="2002:5143:8351:1" > > Or, if you want to use 0 for xl1, please set stf_interface_ipv6_slaid. I changed my ipv6_prefix_xl1 variable as you suggested, and I'm not getting any errors at boot now, thanks! However, it still doesn't seem to work properly. When pinging an IPv6 host from a box in my local subnet, I'm getting this warning on the box running rtadvd(8) : cannot forward src fe80:0001::0a00:20ff:fef9:8c7a, dst 3ffe:8114:1000::036b, nxt 58, rcvif xl0, outif stf0 And I don't receive any ping back, though it works if I ping from the router. Moreover, the boot scripts still display : IPv4 mapped IPv6 address support=NO Even though stf(4) is configured properly. Any ideas ? Thanks, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: problems with stf(4) and ipv6_gateway_enable
Hi,
> On Tue, 5 Nov 2002 17:00:40 -0800
> Maxime Henrion <[EMAIL PROTECTED]> said:
mux>ipv6_enable="YES"
mux>ipv6_defaultrouter="2002:c058:6301::" # Use this for 6to4 (RFC 3068)
mux>ipv6_prefix_xl1="2002:5143:8351:"
mux>stf_interface_ipv4addr="81.67.131.81"
It seems you do configure your box as follows:
(6to4 router)
| 2002:c058:6301::
|
|
| stf0
| 2002:5143:8351:0::1
(your box)
| xl1
| 2002:5143:8351:0:EUI-64
|
--+
2002:5143:8351:0::/64
You cannot share 2002:5143:8351:0::/64 between xl1 and stf0. Please
don't use same SLA-ID for xl1 and stf0. If you want to use 0 for stf0
(default of stf_interface_ipv6_slaid), please use non-zero SLA-ID for
xl1 like:
ipv6_prefix_xl1="2002:5143:8351:1"
Or, if you want to use 0 for xl1, please set stf_interface_ipv6_slaid.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: NFS functions does *NOT* check if they really have allocated any memory
In message <[EMAIL PROTECTED]>, Archie Cobbs wri tes: >Oops, you're right.. sorry for the misinformation. > >Sounds like a bug to me (did Iasen file a PR?) kern/38872 already exists, and I'm sure there is a much older PR that also describes this problem. Basically it is hard to fix because the errors are detected so deep within functions and macros that were never designed to correctly handle mbuf allocation failures. I think the most feasable solution would be to use libmchain or something like it, but even that is a huge amount of work. The workaround is of course just setting nmbclusters/nmbufs so high that they never run out... Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: NFS functions does *NOT* check if they really have allocated anymemory
Harti Brandt writes: > IK>> > As I experience system crushes at time of mbufs exhaustion I've compiled > IK>> > a debug kernel and traced the problem. I seems the NFS functions > IK>> > (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have > IK>> > allocated memory by MGET macro. > IK>> > IK>> No check is necessary if M_WAIT is specified; the M_GET() function > IK>> is always successful in that case. Same for malloc(). > > Wrong. malloc() returns always successful with M_WAIT, M_GET not. There > is a timeout the M_GET() will wait, but the it will return NULL. Oops, you're right.. sorry for the misinformation. Sounds like a bug to me (did Iasen file a PR?) -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: bpf
On Wed, Nov 06, 2002 at 10:03:06AM +0200, Petri Helenius wrote: > > The specific problem with bpf is that one might have a half-full buffer > of captured data when the select timeout hits. In that case the select > returns with no FDs ready while I think it really should return with > the bpf fd. (and if you look at the code on sys/net/bpf.c, there is > timeout handling towards that goal) but I?ve yet to figure out where it goes > wrong. > > IMO, at timeout the code should check if bd_slen > 0 and if yes, > do ROTATE_BUFFERS and bpf_wakeup() The bpf timeout has nothing to do with the select timeout. Two separate facilities. > The functionality I?m looking for is to get all the packets accumulated, say > in 1 second in single read regardless of if I got a buffer?s full of data. Then do a select with no FDs just to get a periodic wakeup. Then at wakeup do the bpf read, having set nonblocking and immediate mode so you don't get stuck in the read. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: bpf
> I believe the select operation on bpf is not functioning as supposed to.
> I'm calling select with 100ms timeout. The bpf interface is listening to
> an interface with constant packet rate, so it's certain that multiple
> packets have been received during the select call. However the fd for
> the bpf device is not set until the bpf buffer is full. (which might be
> several seconds away since I'm using fairly large bpf buffers)
How about to call ioctl(fd, BIOCSRTIMEOUT, &timeval) ?
I think select(2) sets the fd for the bpf if the bpf buffer is full,
or if the bpf buffer is not empty after timed out.
If you also want select(2) sets the fd for the bpf in the case where
the bpf buffer is empty after timed out (I guess you do not want...:-),
you might want the following patch.
Actually, I had a different problem when I use pcap/bpf on pthread
environment; The fourth argument 'read-timeout' of pcap_open_live()
does not work when the bpf buffer is empty. The following patch
solved my problem. I think it could also be applied to your case.
In the read(2) system call procedure, the difference between
with/without pthread is that bpfread() is called when without pthread,
while bpfpoll() is called when with pthread. Note: in the select(2)
system call procedure, bpfpoll() is called. On timed out, bpfread()
returns even if d->bd_slen == 0. On the other hand, on timed out,
bpfpoll() returns POLLIN|POLLRDNORM bits only if d->bd_slen != 0.
The following patch makes bpfpoll() returns POLLIN|POLLRDNORM bits
even if d->bd_slen == 0 on timed out and also makes bpfread() returns 0
after bpfpoll() returns those bits.
Noritoshi
=
<>
--- sys/net/bpf.c-ORG Mon Apr 15 06:41:48 2002
+++ sys/net/bpf.c Wed Oct 2 16:55:53 2002
@@ -480,7 +480,7 @@
* have arrived to fill the store buffer.
*/
while (d->bd_hbuf == 0) {
- if ((d->bd_immediate || timed_out) && d->bd_slen != 0) {
+ if (d->bd_immediate && d->bd_slen != 0) {
/*
* A packet(s) either arrived since the previous
* read or arrived while we were asleep.
@@ -488,6 +488,8 @@
*/
ROTATE_BUFFERS(d);
break;
+ } else if (timed_out) {
+ goto timedout;
}
/*
@@ -512,6 +514,7 @@
return (error);
}
if (error == EWOULDBLOCK) {
+ timedout:
/*
* On a timeout, return what's in the buffer,
* which may be nothing. If there is something
@@ -1095,8 +1098,8 @@
* (d->bd_hbuf != NULL && d->bd_hlen != 0)
*/
if (d->bd_hlen != 0 ||
- ((d->bd_immediate || d->bd_state == BPF_TIMED_OUT) &&
- d->bd_slen != 0))
+ (d->bd_immediate && d->bd_slen != 0) ||
+ d->bd_state == BPF_TIMED_OUT)
revents |= events & (POLLIN | POLLRDNORM);
else {
selrecord(p, &d->bd_sel);
=
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: USB ethernet problem
On Tue, Nov 05, 2002 at 09:05:47PM +0300, Anton Vinokurov wrote: > Hi! > > I am running FreeBSD 4.7-release and try to use ATEN UC10T USB-to-Ethernet > adapter. Unfortunately it causes my system to print something like: > kue0: watchdog timeout > kue0: usb error on tx: TIMEOUT > following by freeze. I got this problem while forwarding 50pps/64kbit UDP > packet stream which comes from Cisco ATA186 voice gateway in several minutes > after call starts. Same time, OpenBSD 3.2 with a similar if_kue.c driver > works fine at least under one day voice traffic load. I tried original > driver and altq modifed with no success. > Could someone suggest me a way to fix my problem? There are a number of bugs in the usb stack in -stable, which are waiting for a merge from -current to get fixed. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = msg07483/pgp0.pgp Description: PGP signature
Re: NFS functions does *NOT* check if they really have allocatedany memory
On Wed, 6 Nov 2002, Iasen Kostov wrote: IK> IK> IK>On Tue, 5 Nov 2002, Archie Cobbs wrote: IK> IK>> Iasen Kostov writes: IK>> > As I experience system crushes at time of mbufs exhaustion I've compiled IK>> > a debug kernel and traced the problem. I seems the NFS functions IK>> > (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have IK>> > allocated memory by MGET macro. IK>> IK>> No check is necessary if M_WAIT is specified; the M_GET() function IK>> is always successful in that case. Same for malloc(). Wrong. malloc() returns always successful with M_WAIT, M_GET not. There is a timeout the M_GET() will wait, but the it will return NULL. harti To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Netgraph and KQUEUE(2)
: 1) Device driver in Netgraph node. When hardware is :activated new Netgraph node is created and new :kevent sent. devd (or something like devd) listens :for these events and does something (loads firmware, :activates device, etc.) Device drivers are not netgraph nodes. They will have a device_t associated with them, which already sends a message via /dev/devctl to devd. You can do anything you want with the results. There's no need to reinvent the wheel that I'm almost done inventing. There's absolutely no need to bring netgraph into it all, and doing so makes it a less generic implementation. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: NFS functions does *NOT* check if they really have allocatedany memory
On Tue, 5 Nov 2002, Archie Cobbs wrote:
> Iasen Kostov writes:
> > As I experience system crushes at time of mbufs exhaustion I've compiled
> > a debug kernel and traced the problem. I seems the NFS functions
> > (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have
> > allocated memory by MGET macro.
>
> No check is necessary if M_WAIT is specified; the M_GET() function
> is always successful in that case. Same for malloc().
If that was true, I should not see any traps 12 , should I ? :)
In case of nfsm_reqh MGET() called as MGET(mb, M_WAIT, MT_DATA) returns
NULL in casese of mbuf exhaustion.
this is fix/test a add to nfsm_reqh() function:
nfs/nfs_subs.c:591
MGET(mb, M_WAIT, MT_DATA);
/*
* This becomes true when there is no more mbufs available.
* If you don't belive me - test it :)
*/
if(mb == 0) {
printf("nfsm_reqh: no memory for header\n");
return NULL;
}
If there was not this check - kernel crushes at this point:
nfs/nfs_subs.c:592 // Of the original file
if (hsiz >= MINCLSIZE) {
MCLGET(mb, M_WAIT);
}
Here is the panic message:
IdlePTD at phsyical address 0x00326000
initial pcb at physical address 0x00299ba0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01d1864
stack pointer = 0x10:0xcd717d68
frame pointer = 0x10:0xcd717d7c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 167 (ls)
interrupt mask = none
trap number = 12
panic: page fault
And backtrace:
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc015182b in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc0151c50 in poweroff_wait (junk=0xc02734ec, howto=-1071173617)
at ../../kern/kern_shutdown.c:595
#3 0xc0241382 in trap_fatal (frame=0xcd717d28, eva=12)
at ../../i386/i386/trap.c:974
#4 0xc0241055 in trap_pfault (frame=0xcd717d28, usermode=0, eva=12)
at ../../i386/i386/trap.c:867
#5 0xc0240c3f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi
= 0,
tf_esi = 0, tf_ebp = -848200324, tf_isp = -848200364, tf_ebx = 1,
tf_edx = 0, tf_ecx = 6685184, tf_eax = 0, tf_trapno = 12, tf_err =
2,
tf_eip = -1071835036, tf_cs = 8, tf_eflags = 66183, tf_esp = 512,
tf_ss = -84812}) at ../../i386/i386/trap.c:466
#6 0xc01d1864 in nfsm_reqh (vp=0xcd70dc00, procid=4, hsiz=72,
bposp=0xcd717dc0) at ../../nfs/nfs_subs.c:593
#7 0xc01d83c5 in nfs3_access_otw (vp=0xcd70dc00, wmode=63, p=0xcbff2080,
cred=0xc131b100) at ../../nfs/nfs_vnops.c:292
#8 0xc01d8dab in nfs_getattr (ap=0xcd717e20) at ../../nfs/nfs_vnops.c:637
#9 0xc018660f in vn_stat (vp=0xcd70dc00, sb=0xcd717ec8, p=0xcbff2080)
at vnode_if.h:276
#10 0xc01865cc in vn_statfile (fp=0xc1320fc0, sb=0xcd717ec8, p=0xcbff2080)
at ../../kern/vfs_vnops.c:451
#11 0xc01468cf in fstat (p=0xcbff2080, uap=0xcd717f80) at
../../sys/file.h:206
.
.
.
(kgdb) l nfs_subs.c:593
588 struct nfsmount *nmp;
589 int nqflag;
590
591 MGET(mb, M_WAIT, MT_DATA); << Here MGET returns NULL in mb
(I'm sure - I saw it :)
592 if (hsiz >= MINCLSIZE)
593 MCLGET(mb, M_WAIT); << At this point kernel
crushes
594 mb->m_len = 0;
595 bpos = mtod(mb, caddr_t);
596
597 /*
As you said - MGET used with M_WAIT flag should never return NULL
pointer. Is this a problem with MGET macro or it is somewhere in functions
that it calls? But wherever is the problem it is a big problem :). It make
(at least) NFS servers unstable and could lead to data loss (when kernel
crashes).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
SPOOFING & NG
HI net'ers !! i read some message on the list archive and someone says that we can use spoofing with ng how can i do spooging with ng like this ??? WAN --- spoofer ( one ng node ) --- lan THANX _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
A Question About NetGraph ????
Hi list; i read NG manual and i cannot get something : 1. is NG just for FreeBSD nodes connection 2. is NG for p2p connection 3. can i use 2 Nodes like this ... LAN ---TCP/IP---NG1---NG connection--NG2---TCP/IP-WAN lan doesn't have the ng run on it and also WAN but between 2 ng-nodes i can have NG connection 4. is the data messages between 2 nodes are compressed THANX _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ICMP question
Hello, I'm using FreeBSD for routing and shaping in my company. Now, I have a problem: each time the pipe queue is full, the router sends : ICMP: Source quench. Please, help me to disable this message. Looking forward to your reply, Vladimir Girnet "MEGADAT.COM" S.R.L. MOLDOVA, Chisinau www.mdl.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: bpf
> I believe you're misunderstanding the meaning of the timeout in select(2). > Timeout applies only when no FDs are ready. The specific problem with bpf is that one might have a half-full buffer of captured data when the select timeout hits. In that case the select returns with no FDs ready while I think it really should return with the bpf fd. (and if you look at the code on sys/net/bpf.c, there is timeout handling towards that goal) but I´ve yet to figure out where it goes wrong. IMO, at timeout the code should check if bd_slen > 0 and if yes, do ROTATE_BUFFERS and bpf_wakeup() Unfortunately I´m not a kernel wizard enough to have fixed this, at least not yet. The functionality I´m looking for is to get all the packets accumulated, say in 1 second in single read regardless of if I got a buffer´s full of data. > > Also, you might be better off setting immediate mode on your bpf fd, > if you want a return before the buffer is full. > Immediate mode practically causes the reader to be waken up for every packet, ending up with huge number of small reads which is highly ineffective. Pete > On Mon, Nov 04, 2002 at 12:12:26AM +0200, Petri Helenius wrote: > > > > I believe the select operation on bpf is not functioning as supposed to. > > I?m calling select with 100ms timeout. The bpf interface is listening to > > an interface with constant packet rate, so it?s certain that multiple packets > > have been received during the select call. However the fd for the bpf > > device is not set until the bpf buffer is full. (which might be several seconds > > away since I?m using fairly large bpf buffers) > > > > Looking at the code I get the impression that if there are packets on the bpf > > buffer when the select timeouts, it should return the fd for the bpf ? > > > > Pete > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the 'Net. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
