Maximum socket buffer sizes
Hi! What are the maximum socket buffer sizes for: net.core.rmem.* net.core.wmem.* net.core.optmem_max As far as i can tell these are ones to adjust when "tuning" e.g. the netlink sockets between the kernel and userspace? I have not been able to find this information anywhere... Best regards Martin -- Failure is not an option. It comes bundled with your Microsoft product. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Maximum socket buffer sizes
Hi! What are the maximum socket buffer sizes for: net.core.rmem.* net.core.wmem.* net.core.optmem_max As far as i can tell these are ones to adjust when tuning e.g. the netlink sockets between the kernel and userspace? I have not been able to find this information anywhere... Best regards Martin -- Failure is not an option. It comes bundled with your Microsoft product. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No buffer space available when using the ip_queue module
Hi! When using the ip_queue module from Netfilter I sometimes get this error: Failed to receive netlink message: No buffer space available Is it possible to make those kernel buffers bigger so that I don't run into this problem? Best regards Martin -- Failure is not an option. It comes bundled with your Microsoft product. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No buffer space available when using the ip_queue module
Hi! When using the ip_queue module from Netfilter I sometimes get this error: Failed to receive netlink message: No buffer space available Is it possible to make those kernel buffers bigger so that I don't run into this problem? Best regards Martin -- Failure is not an option. It comes bundled with your Microsoft product. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops when using the Netfilter QUEUE target
On Wed, Apr 25, 2001 at 04:24:46PM +1000, James Morris wrote: > > I have encountered a problem (perhaps a bug)! The attached code makes my kernel >oops > > in some cases when injecting new packets through Netfilter's QUEUE target. The >problem > > only appears when the original packet is a TCP packet; i have tried with ICMP and >UDP packets > > also but this does not trigger any oops. I have tried to code on several computers >and they > > all oops. The following description regards the case when submitting new packets >instead > > of TCP packets. > > Please try the patch below. So i did and it seems to work just fine (= no more oops') under 2.4.3/2.4.2-ac21! The packets being sent also seems to be correct; James you're the man :-) BTW could you describe the problem? And why it caused an oops? Best regards, Martin -- There's no place like ~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops when using the Netfilter QUEUE target
On Wed, Apr 25, 2001 at 04:24:46PM +1000, James Morris wrote: I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops in some cases when injecting new packets through Netfilter's QUEUE target. The problem only appears when the original packet is a TCP packet; i have tried with ICMP and UDP packets also but this does not trigger any oops. I have tried to code on several computers and they all oops. The following description regards the case when submitting new packets instead of TCP packets. Please try the patch below. So i did and it seems to work just fine (= no more oops') under 2.4.3/2.4.2-ac21! The packets being sent also seems to be correct; James you're the man :-) BTW could you describe the problem? And why it caused an oops? Best regards, Martin -- There's no place like ~ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Semi-OT] Dual Athlon support in kernel
On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote: > Also, what is a good rock solid SCSI RAID controller? Money is > no object. Reliability, performance and Linux compatibility are > though. I have very good experiences with the Mylex controllers/drivers! But then again I also have good experiences with the new-style SW-RAID; it performs very well indead and it is quite cheap :) Regards, Martin -- There's no place like ~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel Oops when using the Netfilter QUEUE target
Hi there!
I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops
in some cases when injecting new packets through Netfilter's QUEUE target. The problem
only appears when the original packet is a TCP packet; i have tried with ICMP and UDP
packets
also but this does not trigger any oops. I have tried to code on several computers and
they
all oops. The following description regards the case when submitting new packets
instead
of TCP packets.
It seems that new packets can not have a length greater than 92 bytes under 2.4.2-ac21
and 76 under 2.4.3; these sizes may vary but the oops can be triggered by choosing
a larger packet size.
Netfilter is configured the following way:
[root@lwb7 ipsecd]# modprobe iptable_filter
[root@lwb7 ipsecd]# modprobe ip_queue
[root@lwb7 ipsecd]# iptables -t mangle -A OUTPUT -d lwb5 -j LOG
[root@lwb7 ipsecd]# iptables -t mangle -A OUTPUT -d lwb5 -j QUEUE
[root@lwb7 ipsecd]# lsmod
Module Size Used by
ipt_LOG 4063 1 (autoclean)
iptable_mangle 2542 0 (autoclean) (unused)
ip_queue5946 0 (unused)
iptable_filter 2533 0 (unused)
ip_tables 14936 3 [ipt_LOG iptable_mangle iptable_filter]
NVdriver 688003 12 (autoclean)
8139too16845 1 (autoclean)
[root@lwb7 ipsecd]# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
LOGall -- anywhere lwb5.it.dtu.dk LOG level warning
QUEUE all -- anywhere lwb5.it.dtu.dk
I have added some printk's in net/code/netfilter.c in nf_reinject() and i seems that
the kernel oops' in info->okfn(skb) (i added printk before and after):
IN= OUT=eth0 SRC=130.225.76.37 DST=130.225.76.35 LEN=60 TOS=0x00 PREC=0x00 TTL=64
ID=173 PROTO=TCP SPT=1025 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0
nf_hook: Verdict = QUEUE.
In nf_reinject() before info->okfn(skb) line 521
Unable to handle kernel NULL pointer dereference at virtual address 02b4
printing eip:
c01e7456
*pde =
Entering kdb (current=0xc68f6000, pid 884) Oops: Oops
due to oops @ 0xc01e7456
eax = 0x05dc ebx = 0xc7acf224 ecx = 0x000e edx = 0xc72f8440
esi = 0xc7cee740 edi = 0x esp = 0xc68f7c90 eip = 0xc01e7456
ebp = 0xc68f7cb0 xss = 0x0018 xcs = 0x0010 eflags = 0x00010287
xds = 0x0018 xes = 0x0018 origeax = 0x = 0xc68f7c5c
kdb>
I will be glad to submit som more (debug) information?!
I really hope someone can help me :)
Best regards,
Martin Clausen
--
There's no place like ~
/* Compile: gcc -o nfcrash nfcrash.c -lipq
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* For CRASH_ME <= 32 everything seems to work (2.4.2-ac21).
* For CRASH_ME > 32 the kernel oops'es in case of TCP traffic (2.4.2-ac21)?!
*
* For CRASH_ME <= 16 everything seems to work (2.4.3).
* For CRASH_ME > 16 the kernel oops'es in case of TCP traffic (2.4.3)?!
*
*/
const int CRASH_ME = 17;
const int ESP_OFF = 0;
unsigned short in_cksum(unsigned short *addr, int len)
{
int nleft = len;
int sum = 0;
unsigned short *w = addr;
unsigned short answer = 0;
while (nleft > 1) {
sum += *w++;
nleft -= 2;
}
if (nleft == 1) {
*(unsigned char *)() = *(unsigned char *) w;
sum += answer;
}
sum = (sum >> 16) + (sum & 0x);
sum += (sum >> 16);
answer = ~sum;
return answer;
}
int main(int argc, char **argv)
{
struct ipq_handle *qh;
struct ipq_packet_msg *qpkt;
struct iphdr *iph;
unsigned char buff[8192];
unsigned char *esppkt;
int esppkt_len;
int type;
int len;
/* Init first (flags are not implemented; yet) */
if ( (qh = ipq_create_handle(0)) == NULL) {
/* Run away... */
ipq_perror("create_handle()");
exit(1);
}
/* We would like to receive not only metadata... */
if (ipq_set_mode(qh, IPQ_COPY_PACKET, sizeof(buff)) < 0) {
ipq_perror("set_mode()");
goto cleanup;
}
/* Now real fun begins... Just stay in loop, read packets,
* accept them if they are IP. */
while (1) {
len = ipq_read(qh, buff, sizeof buff, 0
Re: [Semi-OT] Dual Athlon support in kernel
On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote: Also, what is a good rock solid SCSI RAID controller? Money is no object. Reliability, performance and Linux compatibility are though. I have very good experiences with the Mylex controllers/drivers! But then again I also have good experiences with the new-style SW-RAID; it performs very well indead and it is quite cheap :) Regards, Martin -- There's no place like ~ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
