Re: Ancient FreeBSD releases online
Poul-Henning Kamp wrote: ftp://phk.freebsd.dk ./386BSD/cd1.iso Can you upload MD5 checksums too? -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /etc/opiekeys permissions?
On Thu, 2005-Jul-14 14:14:42 +0400, Eygene A. Ryabinkin wrote: > Playing with OPIE I've noticed that the /etc/opiekeys have mode 644. ... > But now it seems to be vulnurable again. Are there any programs that are >run in non-root mode and they do want to use OPIE? If there is no such >programs, why the permissions are so strange? Since an OPIE password can only be used once, any program that uses OPIE needs to be able to read and write /etc/opiekeys. There is no valid reason for a program to just want to read the file. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /etc/opiekeys permissions?
> Since an OPIE password can only be used once, any program that uses OPIE > needs to be able to read and write /etc/opiekeys. There is no valid reason > for a program to just want to read the file. Good point. I've missed it. Thanks. So, the arguments for permissions 0600 instead of 0644 are getting stronger. Probably I should make a PR? -- rea ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help w/panic under heavy load - 5.4
On 2005-07-20 11:41, Edwin <[EMAIL PROTECTED]> wrote:
> I'm trying to understand the particulars about this - I get the null pointer
> part, but as to ip_fragment - it's fragmenting mbufs to handle ip packets
> during switching? and its failing trying to copy data past the end of the
> chain?
ip_fastfwd() thinks that it should fragment the packet because it somehow
calculates a bogus ``mtu'' value. See the mtu value in frame 12 of the stack
trace below.
> mbsd05# kgdb kernel.debug /tmp/crash/vmcore.3
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
> #0 doadump () at pcpu.h:159
> 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) where
> #0 doadump () at pcpu.h:159
> #1 0xc04611f6 in db_fncall (dummy1=0, dummy2=0, dummy3=-1, dummy4=0xc76bf9f4
> "(οΏ½kοΏ½")
> at /usr/src/sys/ddb/db_command.c:531
> #2 0xc0461004 in db_command (last_cmdp=0xc08c9264, cmd_table=0x0,
> aux_cmd_tablep=0xc08483b8,
> aux_cmd_tablep_end=0xc08483d4) at /usr/src/sys/ddb/db_command.c:349
> #3 0xc04610cc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
> #4 0xc0462c51 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
> #5 0xc0627af2 in kdb_trap (type=3, code=0, tf=0xc76bfb30) at
> /usr/src/sys/kern/subr_kdb.c:468
> #6 0xc07b6394 in trap (frame=
> {tf_fs = -949288936, tf_es = -1067319280, tf_ds = -1065222128, tf_edi =
> 1, tf_esi = -1065
> 197495, tf_ebp = -949224592, tf_isp = -949224612, tf_ebx = -949224548, tf_edx
> = 0, tf_ecx = -10
> 60921344, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067288461, tf_cs
> = -1065222136, tf_eflags = 658, tf_esp = -949224560, tf_ss = -1067376657}) at
> /usr/src/sys/i386/i386/trap.c:584
> #7 0xc07a69ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140
> #8 0xc76b0018 in ?? ()
> #9 0xc0620010 in schedcpu () at /usr/src/sys/kern/sched_4bsd.c:461
> #10 0xc0611fef in panic (fmt=0xc0820008 "default") at
> /usr/src/sys/kern/kern_shutdown.c:550
> #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1)
> at /usr/src/sys/kern/uipc_mbuf.c:385
> #12 0xc069b694 in ip_fragment (ip=0xc11bd80e, m_frag=0xc76bfc6c,
> mtu=-1056787456,
> if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967
The ``mtu'' is an extremely small integer value, which is definitely a problem
here. Somehow, ip_fastforward() calculates a very wrong value for the ``mtu''.
> 6933c1 in ip_fastforward (m=0xc11ab100) at
> /usr/src/sys/netinet/ip_fastfwd.c:572
If you have this particular crash dump, can you show me a dump of the
``ro.ro_rt->rt_rmx'' and the ``ifp'' structure that ip_fastforward() is using?
One of these two seems to have an invalid mtu value.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atheros, hardware access layer, collisions
On 7/21/05, David Malone <[EMAIL PROTECTED]> wrote: > On Wed, Jul 20, 2005 at 10:03:49PM -0500, Sam Pierson wrote: > > I think there is still collision detection happening on the hardware > > level. I think I have to disable the retransmission of frames > > which are lost due to collisions. Here's my reasoning: In the lab, two > > hosts are sending packets to the middle guy at the same time. > > After examining the traffic on the middle guy, one packet will > > arrive before the other one (sometimes in different order) and > > the second packet comes 500-1200us after the first. From this, > > I think some retransmission is happening because of collision, > > since the results are seemingly random. > > Since introducing random delays before transmission and using carrier > sensing are basic features of the 802.11 MAC, I'd be suprised if > you can stop the hardware doing it. To reduce the effects as much > as possible, you could try trying to reduce the number of retransmission > attempts and changing the cwmin parameter to be small. Even if you > do this, you'll still need to transmit the packets quite close to > one another (probably within 20us) to avoid the carrier sense stuff > kicking in. > > What effect are you trying to achieve? I've got two computers synchronized to send one packet each to this machine sitting between them. This machine responds with a packet to each that it receives (on the application level, not in the control frame space), so if there is a collision, I don't want the middle machine to respond and I don't want the senders to retransmit when they don't receive an ACK control frame after they send their data packet (again, this packet is up on the transport layer, so more control frames might be sent). Normal operation (regular connectivity) is not needed on the two senders, so screwing up their retransmission scheme isn't a problem. -Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPv4 Link Local support in FreeBSD
Hi All, Does FreeBSD support IPv4 Link Local addresses as per RFC 3927 ? -Arul Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help w/panic under heavy load - 5.4
On 2005-07-21 14:57, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> On 2005-07-20 11:41, Edwin <[EMAIL PROTECTED]> wrote:
> > I'm trying to understand the particulars about this - I get the null pointer
> > part, but as to ip_fragment - it's fragmenting mbufs to handle ip packets
> > during switching? and its failing trying to copy data past the end of the
> > chain?
>
> ip_fastfwd() thinks that it should fragment the packet because it somehow
> calculates a bogus ``mtu'' value. See the mtu value in frame 12 of the stack
> trace below.
>
> > #10 0xc0611fef in panic (fmt=0xc0820008 "default") at
> > /usr/src/sys/kern/kern_shutdown.c:550
> > #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1)
> > at /usr/src/sys/kern/uipc_mbuf.c:385
> > #12 0xc069b694 in ip_fragment (ip=0xc11bd80e, m_frag=0xc76bfc6c,
> > mtu=-1056787456,
> > if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967
>
> The ``mtu'' is an extremely small integer value, which is definitely a problem
> here. Somehow, ip_fastforward() calculates a very wrong value for the
> ``mtu''.
The check for finding the right MTU in ip_output.c is a bit different,
as it includes a check for RTF_UP:
777:if (ip->ip_off & IP_DF) {
778:error = EMSGSIZE;
779:/*
780: * This case can happen if the user changed the MTU
781: * of an interface after enabling IP on it. Because
782: * most netifs don't keep track of routes pointing to
783: * them, there is no way for one to update all its
784: * routes when the MTU is changed.
785: */
786:if ((ro->ro_rt->rt_flags & (RTF_UP | RTF_HOST)) &&
787:(ro->ro_rt->rt_rmx.rmx_mtu > ifp->if_mtu)) {
788:ro->ro_rt->rt_rmx.rmx_mtu = ifp->if_mtu;
789:}
790:ipstat.ips_cantfrag++;
791:goto bad;
792:}
The check for RTF_UP doesn't exist in ip_fastfwd.c, except perhaps
through the ip_findroute() call. I'm probably confused, but it seems
that ip_findroute() in ip_fastfwd.c may still return a route entry for a
gateway that is not yet RTF_UP, since the check for the RTF_UP flag is
not done for the dst.rt_gateway route entry too.
This may be the cause of the invalid MTU value you're seeing. Can you
try the following patch for ip_fastfwd.c?
The diff is also available online at:
http://people.freebsd.org/~keramida/diff/fastfwd-mtu.patch
%%%
Index: ip_fastfwd.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fastfwd.c,v
retrieving revision 1.28
diff -u -r1.28 ip_fastfwd.c
--- ip_fastfwd.c4 May 2005 13:09:19 - 1.28
+++ ip_fastfwd.c21 Jul 2005 14:38:35 -
@@ -537,12 +537,13 @@
}
/*
-* Check if packet fits MTU or if hardware will fragement for us
+* Check if packet fits MTU or if hardware will fragment for us.
+* If necessary, update the MTU of the route entry too.
*/
- if (ro.ro_rt->rt_rmx.rmx_mtu)
- mtu = min(ro.ro_rt->rt_rmx.rmx_mtu, ifp->if_mtu);
- else
- mtu = ifp->if_mtu;
+ if ((ro.ro_rt.rt_flags & (RTF_UP | RTF_HOST)) &&
+ ro.ro_rt->rt_rmx.rmx_mtu > ipf->if_mtu)
+ ro.ro_rt->rt_rmx.rmx_mtu = ipf->if_mtu;
+ mtu = ifp->if_mtu;
if (ip->ip_len <= mtu ||
(ifp->if_hwassist & CSUM_FRAGMENT && (ip->ip_off & IP_DF) == 0)) {
%%%
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atheros, hardware access layer, collisions
> I've got two computers synchronized to send one packet each to this > machine sitting between them. This machine responds with a packet > to each that it receives (on the application level, not in the control frame > space), so if there is a collision, I don't want the middle machine to > respond and I don't want the senders to retransmit when they don't > receive an ACK control frame after they send their data packet (again, > this packet is up on the transport layer, so more control frames might > be sent). Normal operation (regular connectivity) is not needed on the > two senders, so screwing up their retransmission scheme isn't a problem. OK - you can probably achieve that by setting the retry limit to be 1, setting CWmin to be very small. However, you'll need to make sure that both machines transmissions are synchronised to better than 20us (which is no mean feat), otherwise carrier sense will foil your plan! David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atheros, hardware access layer, collisions
> OK - you can probably achieve that by setting the retry limit to > be 1, setting CWmin to be very small. I was looking for this in the ah.h and the ah_desc.h files. Are they someplace else, or maybe this is a system call? I can't find anything about the retry limit (<-- CWmin = retry?) Thanks, Sam >However, you'll need to make > sure that both machines transmissions are synchronised to better > than 20us (which is no mean feat), otherwise carrier sense will > foil your plan! > > David. > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sendmail and clamav milter setting
Hi I have a clamd server(antivirus server), opening TCP connection instead of the unix domain socket. Next, I have another separate sendmail server. Now I want to do virus scanning. So, should the clamav-milter daemon be on the sendmail server or the antivirus server? I have this configuration and this works: Sendmail SRV <-local domain socket-> clamav-milter <- tcp -> clamd server (server A) (server A) (server b) Or this is the correct one: Sendmail SRV <-tcp-> clamav-milter <- tcp/domain socket -> clamd server (server A) (server b) (server b) Regards Patrick Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sendmail and clamav milter setting
In the last episode (Jul 21), Patrick Dung said: > I have a clamd server(antivirus server), opening TCP connection > instead of the unix domain socket. > > Next, I have another separate sendmail server. Now I want to do virus > scanning. > > So, should the clamav-milter daemon be on the sendmail server or the > antivirus server? > > I have this configuration and this works: > > Sendmail SRV <-local domain socket-> clamav-milter <- tcp -> clamd > server (server A) (server A) (server b) This is probably slightly faster than the one below, since the sendmail-milter connection is more chatty (you may get a callback for each header, etc). > Or this is the correct one: > Sendmail SRV <-tcp-> clamav-milter <- tcp/domain socket -> clamd server > (server A) (server b) (server b) -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: sendmail and clamav milter setting
On Thursday, July 21, 2005 5:19 PM, Patrick Dung <> unleashed the infinite monkeys and produced: > So, should the clamav-milter daemon be on the sendmail server or the > antivirus server? You may get more relevant information on the clamav list, or even comp.mail.sendmail (since the question isn't FreeBSD specific). Actually, I'm fairly certain it's been discussed before, though not necessarily for clamav, on comp.mail.sendmail. > I have this configuration and this works: > > Sendmail SRV <-local domain socket-> clamav-milter <- tcp -> clamd > server > (server A) (server A) (server b) > > Or this is the correct one: > Sendmail SRV <-tcp-> clamav-milter <- tcp/domain socket -> clamd server > (server A) (server b) (server b) To some degree the answer is: either. It'll depend on the relative hardware specs, the network speed and the sizes of the emails. Try both and see what's faster, on average, for you. -- Rob | Oh my God! They killed init! You bastards! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atheros, hardware access layer, collisions
> I was looking for this in the ah.h and the ah_desc.h files. Are they > someplace else, or maybe this is a system call? I can't find anything > about the retry limit (<-- CWmin = retry?) Thanks, CWmin is a setting that controls the random delay before packets are transmitted. Search for tqi_cwmin in the driver. The retry limit says how many times the MAC should retry if it gets a collision while trying to transmit - I think it is controled by the tqi_shretry and tqi_lgretry values. In the driver in 6.X you can (in principle) set these values at the time the transmit queues are configured. David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: per file lock list
:Hi, : :We have a question: how to get all POSIX locks for a given file? :.. : :As far as I know, existing API does not allow to retrieve all file :locks. Therefore, we need to use kernel internal structures to get all :... :So the question: is there an elegant way to get the lock list for a given file? : :Thank you in advance. You can use F_GETLK to iterate through all posix locks held on a file. From man fcntl: F_GETLKGet the first lock that blocks the lock description pointed to by the third argument, arg, taken as a pointer to a struct flock (see above). The information retrieved overwrites the information passed to fcntl() in the flock structure. If no lock is found that would prevent this lock from being created, the structure is left unchanged by this function call except for the lock type which is set to F_UNLCK. So what you do is you specify a lock description that covers the whole file and call F_GETLK. You then use the results to modify the lock description to a range that starts just past the returned lock for the next call. You continue iterating until F_GETLK tells you that there are no more locks. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atheros, hardware access layer, collisions
David Malone wrote: I was looking for this in the ah.h and the ah_desc.h files. Are they someplace else, or maybe this is a system call? I can't find anything about the retry limit (<-- CWmin = retry?) Thanks, CWmin is a setting that controls the random delay before packets are transmitted. Search for tqi_cwmin in the driver. The retry limit says how many times the MAC should retry if it gets a collision while trying to transmit - I think it is controled by the tqi_shretry and tqi_lgretry values. In the driver in 6.X you can (in principle) set these values at the time the transmit queues are configured. You need to set cwmin on the tx q as David describes. Be sure to set the parameters you set into the hardware; check the wme update code for the correct logic. For the other thing just set the tx descriptor to do 1 try. Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Bus Driver probe and attach device
Hi: I'm trying to written Azalia (HD Audio) driver for freebsd now. The HDA controller is a standard controller, which can take max 15 codecs. I'm planning made it be a bus driver (azalia bus). I tried to read the PCI, USB and Firewire driver code be sample. It looks: 1. Detect codec which already connected to azalia controller. 2. call device_add_child(azbus_dev, NULL, -1); to create a child device, which attach to azalia bus driver. 3. allocate memory to put codec info (e.g. device id, vendor id, revision..etc), and call device_set_ivars(codec_dev, codec_info); save the codec_info ptr into device's ivars. 4. Continue 1 ~ 3, untin all available codecs be added. After all codecs be added, I call the device_probe_and_attach(azbus_dev);, but there is no thing happend. Then I try to call bus_generic_attach(azbus_dev);, the codecs driver probe function be called. Is this correct (use bus_generic_attach()), and I'm interested the detail. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
