Re: Development version 1.9.2 released - Oops
Hello Everyone, This happened only once. But we have only brought up a kernel with it today :). It appeared to occur when an iptables cmd was issued. Since then (and the PC rebooting) we have not had it happen. We are not using the tproxy filter yet. Also, where is a FAQ on a typical install of this for Squid? I have Squid now patched and I believe I can fuddle through it, but would rather use someone else's notes ;). thanks, JES ksymoops 2.4.5 on i686 2.6.4-rc2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.4-rc2/ (default) -m /boot/System.map-2.6.4-rc2 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Mar 8 12:07:13 pink kernel: kernel BUG at mm/slab.c:1316! Mar 8 12:07:13 pink kernel: invalid operand: 0000 [#1] Mar 8 12:07:13 pink kernel: CPU: 1 Mar 8 12:07:13 pink kernel: EIP: 0060:[<c013c159>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Mar 8 12:07:13 pink kernel: EFLAGS: 00010202 Mar 8 12:07:13 pink kernel: eax: 00000033 ebx: f6ee3fec ecx: c03b4e30 edx: c0306c7c Mar 8 12:07:13 pink kernel: esi: f8a1dc18 edi: f8a1dc18 ebp: f6ee3e68 esp: e433df3c Mar 8 12:07:13 pink kernel: ds: 007b es: 007b ss: 0068 Mar 8 12:07:13 pink kernel: Stack: c02c8c60 f8a1dc08 00002000 e433df58 f6ee3eb0 c0000000 ffffffc0 00000080 Mar 8 12:07:13 pink kernel: 00000000 f8a20f00 e433c000 c03082f0 f88b40b6 f8a1dc08 00000040 00000080 Mar 8 12:07:13 pink kernel: 00002000 00000000 00000000 00000000 f8a1a3a4 0807d6a0 c030830c f88b400f Mar 8 12:07:13 pink kernel: [<f88b40b6>] ip_nat_init+0x42/0x1bf [iptable_nat] Mar 8 12:07:13 pink kernel: [<f8a1a3a4>] init_or_cleanup+0x2a/0xba [iptable_nat] Mar 8 12:07:13 pink kernel: [<f88b400f>] init+0xf/0x13 [iptable_nat] Mar 8 12:07:13 pink kernel: [<c01346dc>] sys_init_module+0x11d/0x20e Mar 8 12:07:13 pink kernel: [<c0108d7f>] syscall_call+0x7/0xb Mar 8 12:07:13 pink kernel: Code: 0f 0b 24 05 ce 84 2c c0 8b 0b e9 74 ff ff ff 8b 47 40 c7 04
EIP; c013c159 <kmem_cache_create+438/506> <=====
ebx; f6ee3fec <__crc_net_ratelimit+27fb1/13b36f> ecx; c03b4e30 <cache_chain_sem+0/14> edx; c0306c7c <log_wait+4/c> esi; f8a1dc18 <__crc_pm_idle+10dd99/244fc7> edi; f8a1dc18 <__crc_pm_idle+10dd99/244fc7> ebp; f6ee3e68 <__crc_net_ratelimit+27e2d/13b36f> esp; e433df3c <__crc_skb_clone_fraglist+37fe19/9833c6>
Code; c013c159 <kmem_cache_create+438/506> 00000000 <_EIP>: Code; c013c159 <kmem_cache_create+438/506> <===== 0: 0f 0b ud2a <===== Code; c013c15b <kmem_cache_create+43a/506> 2: 24 05 and $0x5,%al Code; c013c15d <kmem_cache_create+43c/506> 4: ce into Code; c013c15e <kmem_cache_create+43d/506> 5: 84 2c c0 test %ch,(%eax,%eax,8) Code; c013c161 <kmem_cache_create+440/506> 8: 8b 0b mov (%ebx),%ecx Code; c013c163 <kmem_cache_create+442/506> a: e9 74 ff ff ff jmp ffffff83 <_EIP+0xffffff83> Code; c013c168 <kmem_cache_create+447/506> f: 8b 47 40 mov 0x40(%edi),%eax Code; c013c16b <kmem_cache_create+44a/506> 12: c7 04 00 00 00 00 00 movl $0x0,(%eax,%eax,1) 1 warning and 1 error issued. Results may not be reliable. -- James B. MacLean macleajb@ednet.ns.ca Department of Education Nova Scotia, Canada
Hi, On Mon, 2004-03-08 at 18:52, James MacLean wrote:
This happened only once. But we have only brought up a kernel with it today :). It appeared to occur when an iptables cmd was issued. Since then (and the PC rebooting) we have not had it happen. We are not using the tproxy filter yet.
Hmm, looks strange, it crashed when initializing the iptable_nat module, while allocating memory. I'll take a look at it, however, I'd need your kernel config (or at least the Netfilter-related parts).
Also, where is a FAQ on a typical install of this for Squid? I have Squid now patched and I believe I can fuddle through it, but would rather use someone else's notes ;).
You should note that 1.9.2 is not compatible with Gianni Tedesco's Squid patches, and that his latest patches are actually quite old and buggy. You probably would have to use TProxy 1.2, which is for Linux 2.4... (Actually I have a patch for 2.6, but it's nor binary compatible with 2.4 versions, so you would have to recompile Squid, nor well-tested.) FAQ for Squid and TProxy? I don't know of any, but you should probably ask Gianni. However, I'd have a few recommendations: - you must turn "client_persistent_connections" off in Squid config - turning "server_persistent_connections" may help - Gianni's tproxy_gid patch is necessary if you would like to run squid as non-root Unfortunately I can't help more regarding Squid. Please contact Gianni Tedesco for more information. -- Regards, Krisztian KOVACS
On Tue, 9 Mar 2004, KOVACS Krisztian wrote:
Hi, On Mon, 2004-03-08 at 18:52, James MacLean wrote:
This happened only once. But we have only brought up a kernel with it today :). It appeared to occur when an iptables cmd was issued. Since then (and the PC rebooting) we have not had it happen. We are not using the tproxy filter yet. Hmm, looks strange, it crashed when initializing the iptable_nat module, while allocating memory. I'll take a look at it, however, I'd need your kernel config (or at least the Netfilter-related parts).
Hi Kovacs, I have applied the patches to a 2.6.4 kernel I run at home. On that PC I can not get it to blow up like the machines at work. One big difference is that the work machines are SMP and this home one is only a single processor ;). Might help. I have not tried the patches on the released 2.6.4 running on the SMP PCs a work.
Unfortunately I can't help more regarding Squid. Please contact Gianni Tedesco for more information.
Thanks aain, I have e-mailed him. take care, JES -- James B. MacLean macleajb@ednet.ns.ca Department of Education Nova Scotia, Canada
On Tue, 9 Mar 2004, KOVACS Krisztian wrote:
You should note that 1.9.2 is not compatible with Gianni Tedesco's Squid patches, and that his latest patches are actually quite old and buggy. You probably would have to use TProxy 1.2, which is for Linux 2.4... (Actually I have a patch for 2.6, but it's nor binary compatible with 2.4 versions, so you would have to recompile Squid, nor well-tested.) Unfortunately I can't help more regarding Squid. Please contact Gianni Tedesco for more information.
Unfortunately I have not heard from Gianni, but I am hoping I might ask a couple of questions :) : 1. When an application sets up for a tproxy foreign source address according to the cttproxy-2.6.3-1.9.2 README, do any other iptables rules need to be added to activate what the application has setup? 2. Gianni's patches had : int f=ITP_CONNECT; struct in_tproxy itp; itp.itp_faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.itp_fport = fwdState->src.sin_port; setsockopt(fd, SOL_IP, IP_TPROXY_ASSIGN, &itp, sizeof(itp)); setsockopt(fd, SOL_IP, IP_TPROXY_FLAGS, &f, sizeof(f)); which I have replaced with : int f=ITP_CONNECT; struct in_tproxy itp; itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.v.addr.fport = fwdState->src.sin_port; setsockopt(fd, SOL_IP, TPROXY_ASSIGN, &itp, sizeof(itp)); setsockopt(fd, SOL_IP, TPROXY_FLAGS, &f, sizeof(f)); Does this appear to be a correct code update? I ask because it compiles clean, strace says the setsockopt() calls are successfull, but the outgoing source addresses are always the Squid PC's address :(. Again, sorry to bother. Would appreciate even a pointer to a small code sample that does the transparent proxy this way that I could learn from. thanks, JES -- James B. MacLean macleajb@ednet.ns.ca Department of Education Nova Scotia, Canada
Hi, On Sat, 2004-03-20 at 03:35, James MacLean wrote:
1. When an application sets up for a tproxy foreign source address according to the cttproxy-2.6.3-1.9.2 README, do any other iptables rules need to be added to activate what the application has setup?
No, but unfortunately the README is out of date, so the parts documenting the setsockopt() calls does not apply to the current code.
2. Gianni's patches had :
int f=ITP_CONNECT; struct in_tproxy itp; itp.itp_faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.itp_fport = fwdState->src.sin_port; setsockopt(fd, SOL_IP, IP_TPROXY_ASSIGN, &itp, sizeof(itp)); setsockopt(fd, SOL_IP, IP_TPROXY_FLAGS, &f, sizeof(f));
which I have replaced with :
int f=ITP_CONNECT; struct in_tproxy itp; itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.v.addr.fport = fwdState->src.sin_port; setsockopt(fd, SOL_IP, TPROXY_ASSIGN, &itp, sizeof(itp)); setsockopt(fd, SOL_IP, TPROXY_FLAGS, &f, sizeof(f));
Does this appear to be a correct code update?
No, unfortunately. The ABI changes made the TPROXY_ASSIGN, etc. options obsolete. You should try something like this: - 8< - struct in_tproxy itp; itp.op = TPROXY_ASSIGN; itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.v.addr.fport = fwdState->src.sin_port; setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)); itp.op = TPROXY_FLAGS; itp.v.flags = ITP_CONNECT; setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)); - 8< -
Again, sorry to bother. Would appreciate even a pointer to a small code sample that does the transparent proxy this way that I could learn from.
See the tests directory inside the .tar.gz, those are up-to-date code covering most of the simple cases. -- Regards, Krisztian KOVACS
On Mon, 22 Mar 2004, KOVACS Krisztian wrote:
No, unfortunately. The ABI changes made the TPROXY_ASSIGN, etc. options obsolete. You should try something like this: - 8< - struct in_tproxy itp;
itp.op = TPROXY_ASSIGN; itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.v.addr.fport = fwdState->src.sin_port; setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)); itp.op = TPROXY_FLAGS; itp.v.flags = ITP_CONNECT; setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)); - 8< -
Excellent. Big thanks! I had to add the TPROXY_ALLOC, but I saw my first proxy connect complete successfully :). I now need to test it with more than one request to make sure it is now correct.
Again, sorry to bother. Would appreciate even a pointer to a small code sample that does the transparent proxy this way that I could learn from.
See the tests directory inside the .tar.gz, those are up-to-date code covering most of the simple cases.
And now a big "I'm sorry". I looked all over but never even noticed that directory in the patches... The examples were exactly what I needed all along. Maybe a pointer in the README so thick headed folks like myself do not miss them ;)? Many thanks again, JES -- James B. MacLean macleajb@ednet.ns.ca Department of Education Nova Scotia, Canada
Hi, On Mon, 2004-03-22 at 16:46, James MacLean wrote:
No, unfortunately. The ABI changes made the TPROXY_ASSIGN, etc. options obsolete. You should try something like this: - 8< - struct in_tproxy itp;
itp.op = TPROXY_ASSIGN; itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.v.addr.fport = fwdState->src.sin_port; setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)); itp.op = TPROXY_FLAGS; itp.v.flags = ITP_CONNECT; setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)); - 8< -
Excellent. Big thanks! I had to add the TPROXY_ALLOC, but I saw my first proxy connect complete successfully :). I now need to test it with more than one request to make sure it is now correct.
TPROXY_ALLOC is only needed when you need the outgoing (source) foreign port _before_ actually initiating the connection. It is useless if you specify the foreign port explicitly. So I think you don't need it. Also note, that instead of specifying the foreign port as well, it may be enough for you to forge the IP address only. This would make it work much better, since in this case the foreign port will be automatically allocated by the Netfilter NAT core. So, I would omit the line setting the foreign source port member of itp: itp.v.addr.fport = 0; Please try if this works for you.
Again, sorry to bother. Would appreciate even a pointer to a small code sample that does the transparent proxy this way that I could learn from.
See the tests directory inside the .tar.gz, those are up-to-date code covering most of the simple cases.
And now a big "I'm sorry". I looked all over but never even noticed that directory in the patches... The examples were exactly what I needed all along. Maybe a pointer in the README so thick headed folks like myself do not miss them ;)?
The README file needs some update anyway, so I'll add some reference to the tests. -- Regards, Krisztian KOVACS
On Mon, 22 Mar 2004, KOVACS Krisztian wrote:
Hi,
On Mon, 2004-03-22 at 16:46, James MacLean wrote:
No, unfortunately. The ABI changes made the TPROXY_ASSIGN, etc. options obsolete. You should try something like this: - 8< - struct in_tproxy itp;
itp.op = TPROXY_ASSIGN; itp.v.addr.faddr.s_addr = fwdState->src.sin_addr.s_addr; itp.v.addr.fport = fwdS tate->src.sin_port; setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)); itp.op = TPROXY_FLAGS; itp.v.flags = ITP_CONNECT; setsockopt(fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp)); - 8< -
Excellent. Big thanks! I had to add the TPROXY_ALLOC, but I saw my first proxy connect complete successfully :). I now need to test it with more than one request to make sure it is now correct.
TPROXY_ALLOC is only needed when you need the outgoing (source) foreign port _before_ actually initiating the connection. It is useless if you specify the foreign port explicitly. So I think you don't need it. Also note, that instead of specifying the foreign port as well, it may be enough for you to forge the IP address only. This would make it work much better, since in this case the foreign port will be automatically allocated by the Netfilter NAT core. So, I would omit the line setting the foreign source port member of itp:
itp.v.addr.fport = 0;
Please try if this works for you.
Thanks again. The original code passed the port of fwdState->src.sin_port which gave an error, so I looked through the samples and saw the ALLOC option. But your suggestion takes less coding, looks cleaner and seems to work fine so far :). JES -- James B. MacLean macleajb@ednet.ns.ca Department of Education Nova Scotia, Canada
participants (2)
-
James MacLean
-
KOVACS Krisztian