Debugging pxeboot on WRAP
pxeboot from OpenBSD3.8 (but also from 3.5, 3.6. and 3.7) fails to PXE boot WRAP appliances with BIOS 1.08 which supports PXE using etherboot (see www.pcengines.ch): PC Engines WRAP.1C/1D/1E v1.08 640 KB Base Memory 130048 KB Extended Memory 01F0 - no drive found ! ROM segment 0xe000 length 0x8000 reloc 0x0002 Etherboot 5.3.12 (GPL) http://etherboot.org Drivers: NATSEMI Images: NBI PXE Exports: PXE Relocating _text from: [00089370,0009b230) to [07eee140,07f0) Boot from (N)etwork (D)isk or (Q)uit? N Probing pci nic... [dp83815] natsemi_probe: MAC addr 00:0D:B9:01:A0:A4 at ioaddr 0X1000 natsemi_probe: Vendor:0X100B Device:0X0020 dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex. dp83815: Transceiver status 7869 advertising 05E1 dp83815: Setting half-duplex based on negotiated link capability. Searching for server (DHCP)... Me: 10.0.0.20, Server: 10.0.0.3, Gateway 10.0.0.1 Loading 10.0.0.3:pxeboot (PXE)done probing: pc0 com0 pci pxe![2.1] --- the cursor stays here Searching the Web also for Soekris (which is similar to WRAP) hints that the A20 gate hack may be the culprit for this halt. Therefore tried to patch /sys/arch/i386/stand/libsa/gateA20.c so that it leaves the A20 gate alone, even though it seems to be already patched as outlined in http://blog.gmane.org/gmane.os.netbsd.devel.embedded/month=20050601 and in NetBSD3 http://releng.netbsd.org/cgi-bin/req-3.cgi?show=504 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/stand/lib/gatea20.c Then I rebuilt pxeboot: cd /sys/arch/i386/stand make scp /usr/src/sys/arch/i386/stand/pxeboot/pxeboot [EMAIL PROTECTED]/tftpboot/ Still, the boot process halts in the 'probing' line, right after 'pxe![2.1]' My /tftpboot/bsd should be ok as the same kernel file boot ok from a CompactFlash card. My /tftpboot/etc/boot.conf is: set tty com0 stty com0 38400 boot tftp:/bsd Do you have any suggestion how I could debug or prevent this freeze, for example by using debug compile flags in the Makefile, etc.? Thanks for any suggestions, Rolf
Re: Debugging pxeboot on WRAP
On Mon, 26 Dec 2005 10:13:50 +0100, Rolf Sommerhalder [EMAIL PROTECTED] wrote: 01F0 - no drive found ! snip My /tftpboot/bsd should be ok as the same kernel file boot ok from a CompactFlash card. Should we assume you have removed the CompactFlash device? Have you tried bsd.rd ? jcr
Re: Debugging pxeboot on WRAP
On 12/26/05, J.C. Roberts [EMAIL PROTECTED] wrote: 01F0 - no drive found ! snip My /tftpboot/bsd should be ok as the same kernel file boot ok from a CompactFlash card. Should we assume you have removed the CompactFlash device? Yes, the CF card is removed, as someone trying PXE on Soekris experienced problems when there was a such drive. But, although the 01F0 - no drive found ! error disappears after inserting a bootable CF card, the pxeboot process still freezes. Have you tried bsd.rd ? No, not yet. Will try that now, even though I expect that it might not work as it was probably built for GENERIC machine and not for a WRAP that uses an National SC1100 'Geode' ? Rolf
OpenBGP+CARP : OpenBGP does not see CARP going into master state
Hi all, I'm running some tests using an out of the box OpenBSD 3.8. OpenBGPd looks fine for eBGP and iBGP links as long as it does not depend on carp. When a bgp peer depends on a carp interface, OpenBGP does not see the interface going master and does not trigger connections up. I tried to bgpctl reload manually, but this does nothing. bgpctl show interfaces always show that carp devices never come back master once they entered backup state. I need to kill/restart bgpd in every case. My config does just include depend on carp3 for one eBGP neighbour in this case. Is this kind of a bug or do I miss something ? It's my first round with this configuration, I could have forgot one important thing ... Thanks in advance for any help. Regards and happy Xmas. -- Sylvain COUTANT ADVISEO http://www.adviseo.fr/ http://www.open-sp.fr/
Re: Debugging pxeboot on WRAP
On 12/26/05, J.C. Roberts [EMAIL PROTECTED] wrote: Have you tried bsd.rd ? Just tried it, but pxeboot does not continue to boot either. tcpdump on the TFTP server reveals that the WRAP's PXE client actually requests and loads the pxeboot file, but does not get that far where it would request the kernel file bsd or bsd.rd. Now trying to understand the various debug switches in the Makefile, hoping that they will reveal more output before the WRAP freezes. Rolf
Re: Multiple IP's thru DHCP on a single NIC
If I remove completely the questions about pf, and leave only the question about getting multiple IP's with dhclient, any takers then ? Is there any way to get multiple IP's thru DHCP, without using multiple NIC's ? Is there any kind of virtualization of the network interfaces, so I could instruct dhclient to get the IP for one of the virtual interfaces, since that would make sense, but I haven't found any way of doing something like that... I'd really like to make this work with OBSD, rather than linux, for many reasons. The reason for not using multiple interfaces is that the ISP provides 5 dynamic IP's, and I need one or two internal NIC's, so having 5 externals on top of that would be pretty cumbersome, if not even impossible with my current hardware (not sure how many open PCI slots are in the MoBo)... Again, any help is appreciated, even if it's just a pointer to some direction. On 12/4/05, turha turha [EMAIL PROTECTED] wrote: Anyone have any suggestions relating to this ? On 12/2/05, turha turha [EMAIL PROTECTED] wrote: On 12/2/05, jared r r spiegel [EMAIL PROTECTED] wrote: On Thu, Dec 01, 2005 at 05:36:24PM +0200, turha turha wrote: Hi! I'm trying to find out if it's possible to get multiple IP's using DHCP to a single NIC. without knowing what the specifics of the DHCP-situation on the ISP's end is, perhaps a safe assumption is that you're going to need different MACs to be the source of the DHCPDISCOVERs/DHCPREQUESTs I'm pretty sure, that at least if I use two different MAC's I'd get two different IP's, I might have tested it, but am not sure though. a *very* simple solution that will probably Just Work (assuming there is nothing on ISP-side that restricts you to just 1 IP, and assuming your dhclient box can accomodate it) would be to get a little hub/switch and use two external NICs in the dhclient box. connect each NIC and the CPE to the switch and run dhclient for both ifaces. IMO, that's a bit crappy solution, I did think of that, but since from the software standpoint what I'm trying to find, at least to my knowledge, is doable, I'll try to make it work, without 2 external NIC's. Of course the box only has 2 NIC's, I guess I could buy a third, since they aren't that expensive, but I'd rather do it with just the two, less cables and all ;-) Also, related to this, OBSD doesn't create an additional virtual interface when using aliases for an IP, is it possible to create an extra interface ? The reason for this is so that in pf.conf I could use the interface name in parenthesis, so when the DHCP changes one of the IP's pf configuration updates automatically. you can still use the interface name in parens regardless of the virtual interface whatnot.. perhaps you mean something like, if there was a physical NIC, 'fxp0' and two virtual interfaces: fxp0.0 and fxp0.1 you could filter based on simply (fxp0) or (fxp)... i thought you could use a macro for ifspec, but either you can't or i'm testing wrong: [/home/jrrs] $ echo X=\fxp0\\npass on \$X all | pfctl -nvf- X = fxp0 pass on fxp0 all [/home/jrrs] $ echo X=\fxp0 lo0\\npass on \$X all | pfctl -nvf- X = fxp0 lo0 stdin:2: syntax error What I'd need would be like having IF fxp0, with two or more virtual interfaces, and then using (fxp0.0) and (fxp0.1) kinda stuff in pf.conf, and this is very related to the last question. What I meant by the reasoning for not having virtual interfaces was that what's the upside of aliases in contrast to virtual interfaces. As far as I know, virtual interfaces in this situation would save the day, ie. I could give different MAC's to different virtual interfaces and then use dhclient on all the interfaces (virtual or otherwise) I wanted to, and use the interface names in parenthesis in pf.conf (again virtual or otherwise). if you had two NICs of the same family (err, driver) from the above suggestion, you could satisfy that with, ieg: pass on fxp all provided the only fxp(4)s you had were the externals (eg, if you have fxp0, fxp1 for external and fxp2 for internal, that may not be desired, however you could put the 'fxp' rules at the top and then specific fxp2 treatment at the bottom) Does anybody know the reasoning behind not creating a virtual interface ? it's not linux? in seriousness, no. other than seeing that virtual interfaces are not created for physical interfaces who exist (maybe they are created with extant physical interfaces, eg trunk(4)), but there's no fxp0.0stuff that i've come across. -- jared [ openbsd 3.8 GENERIC ( oct 30 ) // i386 ] Thanks for the suggestions though.
Re: Debugging pxeboot on WRAP
After inserting some printf() debug statements into /sys/arch/i386/stand/libsa/pxe.c I found that the call to the assembler subroutine pxe_call(PXENV_GET_CACHED_INFO); never returns. It looks like either there is something wrong with that call, or with the PXE code from Etherboot. Rolf
Re: Debugging pxeboot on WRAP
The posting http://www.monkey.org/openbsd/archive2/bugs/200503/msg1.html is interesting, as it points out that there has already been a problem with pxe_call. single-stepping back into pxeboot. Five instructions later, I hit the lockup point at 4012:403c. The instruction causing the problem is: addrsize opsize lgdt [ds:0x45e80] which is the line marked Load the GDT in the following code from pxe_call.S in the OpenBSD source: /* * real_to_prot() * * Switch the processor back into protected mode. */ .globlreal_to_prot real_to_prot: .code16 xorw %ax, %ax movw %ax, %ds/* Load %ds so we can get at Gdtr */ data32 addr32 lgdt Gdtr /* Load the GDT */ ... Note the address [ds:0x45e80] that this resolves to in the pxeboot binary. In particular, note that the offset contains five hexadecimal digits. We're allegedly in real-mode at this point. We can't access more than 64k in each segment, yet this instruction is trying to access data at an offset of approximately 279k. The CPU doesn't like this. Not sure whether this issue was fixed in OpenBSD yet. That code in OpenBSD3.8 is /sys/arch/i386/stand/libsa/pxe_call.S ... /* * real_to_prot() * * Switch the processor back into protected mode. */ .globl real_to_prot real_to_prot: .code16 movw$LINKADDR 4, %ax /* We're linked to LINKADDR/16: */ movw%ax, %ds data32 addr32 lgdt (Gdtr - LINKADDR)/* Reload the GDT */ movl%cr0, %eax /* Enable protected mode */ orl $CR0_PE, %eax movl%eax, %cr0 data32 ljmp $S32TEXT, $r2p32 /* Reload %cs, flush pipeline */ r2p32: .code32 /* Reload 32-bit %ds, %ss, %es */ movl$S32DATA, %eax mov %ax, %ds mov %ax, %ss mov %ax, %es ... Ah yes, according to CVS log http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/libsa/pxe_call.S that real/protected mode problem should be patched since v1.2. But did current v1.3 eventually break it again? Rolf
Re: Debugging pxeboot on WRAP
No, not yet. Will try that now, even though I expect that it might not work as it was probably built for GENERIC machine and not for a WRAP that uses an National SC1100 'Geode' ? Doesn't really help you, but GENERIC runs just fine on Geode machines...
Re: Debugging pxeboot on WRAP
Rolf Sommerhalder 26-Dec-05 09:13 pxeboot from OpenBSD3.8 (but also from 3.5, 3.6. and 3.7) fails to PXE boot WRAP appliances with BIOS 1.08 which supports PXE using etherboot (see www.pcengines.ch): : Probing pci nic... [dp83815] natsemi_probe: MAC addr 00:0D:B9:01:A0:A4 at ioaddr 0X1000 natsemi_probe: Vendor:0X100B Device:0X0020 dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex. dp83815: Transceiver status 7869 advertising 05E1 dp83815: Setting half-duplex based on negotiated link capability. Searching for server (DHCP)... Me: 10.0.0.20, Server: 10.0.0.3, Gateway 10.0.0.1 Loading 10.0.0.3:pxeboot (PXE)done probing: pc0 com0 pci pxe![2.1] --- the cursor stays here : Searching the Web also for Soekris (which is similar to WRAP) hints that the A20 gate hack may be the culprit for this halt. This is very unlikely to have anything to do with it, as I used the Soekris while implementing pxeboot on OpenBSD (based on the NetBSD code). Still, the boot process halts in the 'probing' line, right after 'pxe![2.1]' The most likely reason is that pxeboot's calls into the PXE stack on the WRAP are failing (to return). Do you have any suggestion how I could debug or prevent this freeze, for example by using debug compile flags in the Makefile, etc.? Get me a WRAP board, babysit the kids for a few evenings, and wait patiently :) If you want to look at it yourself, make sure you understand i386 assembler, the PXE specification, and protected-to-real-and-back mode switching. You could find out if pxe_call works at all on the WRAP in its current implementation by putting a printf() after it, and seeing if there' any output. Look in pxe.c:pxe_init(). Tom
plz help + UNIX NETWORK PROGRAMMING
Dear I installed the package autoconf but still day time client is not working following error occur plz help [EMAIL PROTECTED] ~]$ gcc -o byteorder byteorder.c byteorder.c:1:17: unp.h: No such file or directory byteorder.c: In function `main': byteorder.c:10: error: `CPU_VENDOR_OS' undeclared (first use in this function) byteorder.c:10: error: (Each undeclared identifier is reported only once byteorder.c:10: error: for each function it appears in.) i am lookinf forward from you misc@openbsd.org
Re: Debugging pxeboot on WRAP
Ah yes, according to CVS log http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/libsa/pxe_call.S that real/protected mode problem should be patched since v1.2. But did current v1.3 eventually break it again? Replacing pxe_call.S v1.3 by v1.2 does unfortunately not solve the problem of pxe_call() never returning. Rolf
Re: Debugging pxeboot on WRAP
On 12/26/05, Tom Cosgrove [EMAIL PROTECTED] wrote: You could find out if pxe_call works at all on the WRAP in its current implementation by putting a printf() after it, and seeing if there' any output. Look in pxe.c:pxe_init(). Thanks, did that and definitely pxe_call() never returns. And it is not specific to pxe_call(PXENV_GET_CACHED_INFO), because I also called pxeinfo() which does a pxe_call(PXENV_UNDI_GET_NIC_TYPE) which never returns neither! As you say, it looks like I might have to refresh rusty gdb skills now, and figure out what 'boch' does (as I am totally inexperienced with baby sitting ;-) Rolf
Re: Debugging pxeboot on WRAP
Rolf Sommerhalder 26-Dec-05 11:45 The posting http://www.monkey.org/openbsd/archive2/bugs/200503/msg1.html is interesting, as it points out that there has already been a problem with pxe_call. Why is that posting interesting? That bug was fixed. I said that the problem would be pxe_call in my last email to [EMAIL PROTECTED] As I said in my last email, if you want to look at it yourself, make sure you understand i386 assembler, the PXE specification, and protected- to-real-and-back mode switching. Thanks Tom Date: Sat, 12 Mar 2005 14:52:02 -0700 (MST) From: Tom Cosgrove [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: [EMAIL PROTECTED] 2005/03/12 14:52:02 Modified files: sys/arch/i386/stand/libsa: pxe_call.S sys/arch/i386/stand/pxeboot: conf.c Log message: On return from real mode, reload the GDT using a 16-bit pointer rather than a 32-bit value. Found by Tim Fletcher tim (at) parrswood (dot) manchester (dot) sch (dot) uk using Etherboot; thanks to Tim and the Etherboot developers who narrowed this down. Also bump the pxeboot version to 1.01. ok weingart@, go ahead deraadt@
Re: plz help + UNIX NETWORK PROGRAMMING
[EMAIL PROTECTED] wrote: Dear I installed the package autoconf but still day time client is not working following error occur plz help [EMAIL PROTECTED] ~]$ gcc -o byteorder byteorder.c byteorder.c:1:17: unp.h: No such file or directory byteorder.c: In function `main': byteorder.c:10: error: `CPU_VENDOR_OS' undeclared (first use in this function) byteorder.c:10: error: (Each undeclared identifier is reported only once byteorder.c:10: error: for each function it appears in.) i am lookinf forward from you misc@openbsd.org Me, I'm just a kibitzer on the list, but there is some painfully missing information. It appears that you have some trouble installing an unspecified package autoconf on an unspecified system. I assume that the package and the system are both some sort of OpenBSD (as opposed to some kind of Linux). There is nothing to suggest whether this is a vax or macppc or sparc. Packages, ports, systems, on OpenBSD appear to NOT be a mix-and-match. Stuff for the wrong system can be expected to fail, consistently. Since none has been specified, the answer is almost certainly that you are mixing things that were never intended to be mixed.
A Little Tip for OpenBSD Users of KDE
Don't use sudo in any konsole session. -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing
Re: A Little Tip for OpenBSD Users of KDE
On Mon, Dec 26, 2005 at 11:39:22AM -0500, Dave Feustel wrote: Don't use sudo in any konsole session. Dave, either you tell us _why_ you think it's bad, or keep your tips to yourself and stop causing confusion. Tobias :)
Re: A Little Tip for OpenBSD Users of KDE
On 12/26/05, Dave Feustel [EMAIL PROTECTED] wrote: Don't use sudo in any konsole session. That's odd. Why shouldn't you use sudo? Mike
Re: A Little Tip for OpenBSD Users of KDE
On 26/12/05, Tobias Ulmer [EMAIL PROTECTED] wrote: On Mon, Dec 26, 2005 at 11:39:22AM -0500, Dave Feustel wrote: Don't use sudo in any konsole session. Dave, either you tell us _why_ you think it's bad, or keep your tips to yourself and stop causing confusion. I assume: http://marc.theaimsgroup.com/?t=11349940351
Re: sound goes unexpectedly on mute
Hy, After some checks i got a new idea: to use sound apps until the sound goes of and to try then to check what could be wrong with the sound. I did that even before, but now i tried something else. I switched the headphones to the maximum and i was able to hear a weak sound. A very low sound, but still perceptible. So, i suspected somethign is wrong with the volume settings. I used mixerctl and outputs.master.mute=on was visible. Somehow, mplayer resets the controls: outputs goes on mute and volume to 255,255. I mean: $ mixerctl -a outputs.master=255,255 outputs.master.mute=on If i manually turn the mute off using mixerctl everithing is ok, the sound is back in. I guess something is buggy in mplayer. Did someone experienced this? I'm not using a /etc/mixectl.conf file, could this be the cause? I think to do a cron job to check the mute option, is it there another approach ? Thanks. Just $16.99/mo. or less. dsl.yahoo.com
asuka -- where/how do I find/repair it to proceed with KDE build??
refer to: www.monkey.org/openbsd/archive/ports/0409/msg00941.html apparently the master copy available has a bad checksum; I've tried -DNO_CHECKSUM and the same with =true after it. Also tried the suggestion to REFETCH this build has taken all day and 12GB on a 1400MHz machine! and I am wondering if I am old fashioned because I think this is bloat! But I need this; Please help. --jg
Re: erratic networking problem
Han Boetes wrote: Ted Unangst wrote: On 12/22/05, Han Boetes [EMAIL PROTECTED] wrote: This problem has been bugging me for month now. It started happening a month after 3.8 got tagged. At least, that's when I started noticing it. So it might be anything. But I suspect the OpenBSD side the most since returning to an older Linux release on the client from a liveCD didn't fix the problem. The OpenBSD server doesn't have a CD-drive. OpenBSD server - linux client Both rtl8169 gigabit networkcards Uploading to the server goes with 11Mbytes/s, the speedlimit of the ide harddrives, but the downloading goes with erratic speeds. 1Mbyte/s at best, 100Kbyte/s most of the time, sometimes no more than 20Kbytes/s and if you use a different protocol (ftp, http)? Yes, I tried ftp and rsync over ssh and nfs. All three have the same problems. anything unusual in netstat -s? Have a look: ip: 1173210 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size data length 0 with header length data size 0 with data length header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (duplicates or out of space) 0 malformed fragments dropped 0 fragments dropped after timeout 0 packets reassembled ok 1164892 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded 0 packets not forwardable 0 redirects sent 1182870 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 fragment floods 0 packets with ip length max ip packet size 0 tunneling packets that can't find gif 0 datagrams with bad address in header 311675 input datagrams checksum-processed by hardware 0 output datagrams checksum-processed by hardware 0 multicast packets which we don't join icmp: 0 calls to icmp_error 0 errors not generated because old message was icmp 0 messages with bad code fields 0 messages minimum length 0 bad checksums 0 messages with bad length Input packet histogram: destination unreachable: 115 0 message responses generated igmp: 0 messages received 0 messages received with too few bytes 0 messages received with bad checksum 0 membership queries received 0 membership queries received with invalid field(s) 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 membership reports sent ipencap: 0 total input packets 0 total output packets 0 packets shorter than header shows 0 packets dropped due to policy 0 packets with possibly spoofed local addresses 0 packets were dropped due to full output queue 0 input bytes 0 output bytes 0 protocol family mismatches 0 attempts to use tunnel with unspecified endpoint(s) tcp: 878085 packets sent 458267 data packets (490187475 bytes) 1133 data packets (976692 bytes) retransmitted 0 fast retransmitted packets 362473 ack-only packets (294077 delayed) 0 URG only packets 0 window probe packets 54002 window update packets 2210 control packets 0 packets hardware-checksummed 860321 packets received 229685 acks (for 489089407 bytes) 16982 duplicate acks 0 acks for unsent data 0 acks for old data 469932 packets (416700992 bytes) received in-sequence 18457 completely duplicate packets (12118924 bytes) 44 old duplicate packets 1566 packets with some duplicate data (175713 bytes duplicated) 200639 out-of-order packets (153176788 bytes) 0 packets (0 bytes) of data after window 0 window probes 1109 window update packets 77 packets received after close 675 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded for missing IPsec protection 0 discarded due to memory shortage 860321 packets hardware-checksummed 0 bad/missing md5 checksums 0 good md5 checksums 742 connection requests
broken anime port, part of KDE
I need to get around this problem; Is adding comments to the KDE makefile the right solution?? I need a work around. Does anyone have any suggestions? --jg PS: Pls excuse me; I'm new to managing zillion line makes! I'm amazed that these are practical (though, the job has been running most of the day, and this is first show stopper.)
Re: RELEASE BUG - ami0: timeout ccb 1
Hi,
Re: RELEASE BUG - ami0: timeout ccb 1
Hi, I have one megaraid i4, but with two channels set up. One raid1 for the OS, and one raid5 with 4x250G hard drives. Currently, my 3 options are: 1) use the older motherboard, P3-450Mhz with 3.8-release which supports both channels. 2) use the newer motherboard, P3-1.4Ghz, with 3.8-stable or -current, but only one channel. Need to acquire another i4, obviously. 3) use 3.7 with the newer motherboard, P3-1.4Ghz which supports both channels. Any recommendations of one over the other? And your source for cheap i4 still open? :) -Tai
Re: A Little Tip for OpenBSD Users of KDE
On Mon, 26 Dec 2005 11:39:22 -0500, Dave Feustel [EMAIL PROTECTED] wrote: Don't use sudo in any konsole session. Dave, I don't think you're nuts but the fear mongering without providing any proof or details of a compromise is questionable at best. If you really were compromised while running OpenBSD, you aren't the first and probably won't be the last. As for leaving a terminal window open with root privs, sudo or su, it has *always* been a bad idea: http://seclists.org/lists/bugtraq/2002/May/0294.html As you can see from what happened to Dug Song and monkey.org, the problem may not be konsole itself, instead, your sudo-enabled konsole session could have been taken over via an exploit in some other application you are running. jcr
Re: How to log all entered commands?
On 12/25/05, ober [EMAIL PROTECTED] wrote: Here is a patch, probably something want to test before using on a production box. http://www.linbsd.org/log_execve.38.patch It logs commands to syslog like this: EXECVE: uid:1000 fullpath:/bin/ls command:ls foo EXECVE: uid:1000 fullpath:/sbin/dmesg command:dmesg EXECVE: uid:1000 fullpath:/usr/bin/touch command:touch fff accessing a user pointer from kernel is an easy denial of service attack.
Re: Greylisting google's gmail servers
On Fri, 23 Dec 2005, Moritz Grimm wrote: Joseph C. Bender wrote: Instead, I suggest to use a ``no rdr'' line after rdr'ing those in the blacklists to spamd. Actually, yes, because it makes your filter rulesets easier to parse visually, but you want the no rdr *first*. This is the configuration that we are using. Uh well, to each his own -- in my case, spews1 hasn't caused any false positives, yet. When I whitelist someone like Gmail and it shows up in SPEWS1 eventually, I really need no more mail from @gmail.com accounts. (Personal choice, and according to the SPEWS FAQ I *should* be doing well with it.) Yeah, except when you need to exchange emails with domains on MCI/UUNETs network, or any of the other collateral damage that is inflicted due to SPEWS' childish behavior, even on spews1. P.S.: Another table with another no rdr line in front with the I really need mail from these guys no matter what-IPs and netblocks is still an option. ;-) Which is a waste of time. If I'm going to go out of my way to whitelist an IP, I don't want to do it twice. The fact that I'm putting something in a list to make sure that no matter what that it can talk to me, I'm sure as hell going to bypass whatever blacklist it may or may not end up on. But you are right, YMMV. -- Signing off, Joseph C. Bender [EMAIL PROTECTED]
flash on OpenBSD
Hi, I just read this article: http://www.kaourantin.net/2005/12/flash-player-8-for-linux-update.html Via OSNews. If there ever was a chance to lobby for support of flash on OpenBSD it is now and there. # Han
Re: erratic networking problem
per engelbrecht wrote: recently had a problem with a NFS server. Lousy performance when getting data (not putting) from most clients (but not all) until they discovered diffs in size of the transmit/receive bufferes. When fixed users felt like going from walking to flying both ways. They do not use OpenBSD but the have different arch and OS as well i.e. might be a similar/related problem. I read an article recently about the tux kernel hackers working on a auto sensing feature for the upcomming 2.6.whatever dealing with this. The test result was quite impressive with performance gains x 10-20 and above. I could be a victim of christmas-lag (too much food, dark strong beer and snaps [danish strong alcoholic drink]) or it could be related. Just a thought. Sounds interesting. But searching on google doesn't show any usefull links. Nor did I find out how to read/set the transmit/receive buffers for either OS. I know how to set them for nfs. But that was not related to my problem since it occured for ftp and ssh as well. And changing the sizes didn't change the behaviour at all. From mount_nfs(8) -r readsize Set the read data size to the specified value. It should normal- ly be a power of 2 greater than or equal to 1024. This should be used for UDP mounts when the ``fragments dropped after timeout'' value is getting large while actively using a mount point. (Use netstat(1) with the -s option to see what this value is.) See the -w option as well. -w writesize Set the write data size to the specified value. Ditto the com- ments w.r.t. the -r option, but using the ``fragments dropped after timeout'' value on the server instead of the client. Note that both the -r and -w options should only be used as a last ditch effort at improving performance when mounting servers that do not support TCP mounts. Makes sense doesn't it? Anyway, replacing my Gigabit NIC with a 100Mbit nic helped. I bet the old pII400 couldn't handle that little thing. # Han
Planned software upgrade
[IMAGE] [IMAGE] [IMAGE] Dear client of Chase Bank, Technical services of the Chase Bank are carrying out a planned software upgrade. We earnestly ask you to visit the following link to start the procedure of confirmation on customers data. To get started, please click the link below: http://www.chase.com//cmserver/users/default/confirm.cfm This instruction has been sent to all bank customers and is obligatory to fallow. Thank you, Customers Support Service. [IMAGE] [IMAGE] [IMAGE] [IMAGE] B) 2005 JPMorgan Chase Co.
Re: erratic networking problem
Han Boetes wrote: per engelbrecht wrote: recently had a problem with a NFS server. Lousy performance when getting data (not putting) from most clients (but not all) until they discovered diffs in size of the transmit/receive bufferes. When fixed users felt like going from walking to flying both ways. They do not use OpenBSD but the have different arch and OS as well i.e. might be a similar/related problem. I read an article recently about the tux kernel hackers working on a auto sensing feature for the upcomming 2.6.whatever dealing with this. The test result was quite impressive with performance gains x 10-20 and above. I could be a victim of christmas-lag (too much food, dark strong beer and snaps [danish strong alcoholic drink]) or it could be related. Just a thought. Sounds interesting. But searching on google doesn't show any usefull links. Nor did I find out how to read/set the transmit/receive buffers for either OS. Can't find the article (typical!). Found this though; http://dsd.lbl.gov/TCP-tuning/linux.html It describe the topic yes, but it's not spot on. I know how to set them for nfs. But that was not related to my problem since it occured for ftp and ssh as well. And changing the sizes didn't change the behaviour at all. From mount_nfs(8) -r readsize Set the read data size to the specified value. It should normal- ly be a power of 2 greater than or equal to 1024. This should be used for UDP mounts when the ``fragments dropped after timeout'' value is getting large while actively using a mount point. (Use netstat(1) with the -s option to see what this value is.) See the -w option as well. -w writesize Set the write data size to the specified value. Ditto the com- ments w.r.t. the -r option, but using the ``fragments dropped after timeout'' value on the server instead of the client. Note that both the -r and -w options should only be used as a last ditch effort at improving performance when mounting servers that do not support TCP mounts. Makes sense doesn't it? Anyway, replacing my Gigabit NIC with a 100Mbit nic helped. I bet the old pII400 couldn't handle that little thing. I'm sure some of our commiters can elaborate further/completly on the gory details of why. I'm afraid I can not, sorry. /per [EMAIL PROTECTED] # Han
a stupid question, and OT to boot
I am just not with it, ie., TCP and such like the rest of you; I am doing other stuff... Here's my question. Two boxes, at different locations. I am modem'ed into a remote box, (call it box REMOTE,) while I am at box LOCAL. I know my IP number (at LOCAL) I don't know the IP number at REMOTE So I am telling the REMOTE system to ping me. How can I look at who is pinging me on the LOCAL box?? Because I want to discover the IP address at box REMOTE. Sorry, I will try to keep OT stuff to a bare minimum, and if I get complaints I will stop. --jg
Re: asuka -- where/how do I find/repair it to proceed with KDE build??
Julesg wrote: this build has taken all day and 12GB on a 1400MHz machine! and I am wondering if I am old fashioned because I think this is bloat! But I need this; Please help. Use packages instead of ports?
Re: erratic networking problem
per engelbrecht wrote: Han Boetes wrote: per engelbrecht wrote: recently had a problem with a NFS server. Lousy performance when getting data (not putting) from most clients (but not all) until they discovered diffs in size of the transmit/receive bufferes. When fixed users felt like going from walking to flying both ways. They do not use OpenBSD but the have different arch and OS as well i.e. might be a similar/related problem. I read an article recently about the tux kernel hackers working on a auto sensing feature for the upcomming 2.6.whatever dealing with this. The test result was quite impressive with performance gains x 10-20 and above. Sounds interesting. But searching on google doesn't show any usefull links. Nor did I find out how to read/set the transmit/receive buffers for either OS. Can't find the article (typical!). Found this though; http://dsd.lbl.gov/TCP-tuning/linux.html It describe the topic yes, but it's not spot on. Ow that will do fine. I also found comparable sysctls for OpenBSD. I'll examine it in the morning, when my brains work again. Thanks for looking this up for me, I appreciate it. # Han
Re: Bug Hunting 101 - Finding The Alpha Bug
Upgraded alphastation to 3.8 and first time in my life hit alpha bug. ;) Kernel panicked while ungziping src.tar.gz. When I hit continue in ddb I was dropped into other panic. There is photos of panic, maybe it helps someone to find alphabug :)) http://secure.lv/~nikns/alphabug/
Yet Another PF (authpf) Question.
Hey, Is there a way to configure authpf to redirect an incoming connection on a specific port _and_ change the packet's source address so that the new destination will correctly respond via the firewall? Quick background: I have a wandering, disorganized, computer-illiterate boss who needs to send mail from his laptop from any network, without changing any of his computer's settings. I've set up postfix to handle this, but it's on a local 192.168.0.0/24 net behind our firewall. One of the networks he needs to be able to send mail from is our local wireless network, same subnet. When he's on the same subnet as the mail server and tries to send an email, the connection gets routed to the firewall, which routes it to the mail server, which then responds directly to his laptop because I can't convince authpf to change the redirected packet's source address. I've tried combinations of: nat on rl0 proto tcp from $user_ip to $ext_ip http://63.200.94.38 port 25 - $int_ip http://192.168.0.128 rdr on rl0 proto tcp from $int_ip http://192.168.0.128 to $ext_iphttp://63.200.94.38port 25 - $smtp_ip http://192.168.0.251 (I think I remember reading that authpf loads its rules bottom-up.) ...and... rdr on rl0 proto tcp from $int_ip http://192.168.0.128 to $ext_iphttp://63.200.94.38port 25 - $smtp_ip http://192.168.0.251 nat on rl0 proto tcp from $user_ip to $ext_ip http://63.200.94.38 port 25 - $int_ip http://192.168.0.128 (Just in case I was wrong.) ...and... rdr on rl0 proto tcp from $user_ip to $ext_ip http://63.200.94.38 port 25 - $smtp_ip nat on rl0 proto tcp from $user_ip to $ext_ip http://63.200.94.38 port 25 - $int_ip http://192.168.0.128 (Which doesn't really make much sense to me, but it was worth trying.) ...and so on. I've also tried using tagging. Although I'm still not terribly comfortable with pf, I've read the man pages and sundry how-tos and have usually been able to figure this stuff out before. Thanks. - Rob.
