Re: Core dump with tip (ucom0 - external modem)
On Apr 26, To Daniel O'Connor wrote: then bt at the gdb prompt. Thanks for taking a look at it. GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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-unknown-freebsd... (no debugging symbols found)... Core was generated by `tip'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.5 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)... done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x08049bd2 in connect () (gdb) bt #0 0x08049bd2 in connect () #1 0x0804d055 in send () #2 0x08049942 in sigprocmask () (gdb) I went and built tip with debugging symbols... (gdb) set args -9600 33230 (gdb) run Starting program: /usr/src/usr.bin/tip/tip/tip -9600 33230 Stale lock on ucom0 PID=6696... overriding. Program received signal SIGSEGV, Segmentation fault. 0x08049cd7 in connect () at acu.c:110 110 if (*cp != '\0') (gdb) bt 10 #0 0x08049cd7 in connect () at acu.c:110 #1 0x0804d4bd in main (argc=1, argv=0xbfbfec48) at tip.c:202 #2 0x08049a42 in _start () (gdb) checking for cp != NULL fixes the seg fault, but it still hangs for me...sigh. Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Loosing STDOUT after file rotation
On Fri, Apr 02, 2004 at 05:19:42PM +0200, Dag-Erling Sm?rgrav wrote: James Housley [EMAIL PROTECTED] writes: I have a program that I have the is supposed to run forever. I log any output to a log file. It is run in a startup script like thie: program_name $err_log 21 The problem is that after newsyslog rotates the $err_log file, no more data is written to the file. I can not stop and restart the program. I can accept a signal. But what do I need to do in program_name to allow the data to be written after the rotation of the file. There is not much you can do unless you modify your program to write directly to the log file instead of stdout (in which case you just need to re-open the log file when you get a SIGHUP), or use something like Apache's logrotate instead of newsyslog (pipe the program's output to logrotate, which takes care of the rest) Or, as an alternative to Apache's logrotate, there is multilog from djb's daemontools package - ports/sysutils/daemontools, http://cr.yp.to/daemontools.html G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. pgp0.pgp Description: PGP signature
Re: Loosing STDOUT after file rotation
Peter Pentchev [EMAIL PROTECTED] writes: Or, as an alternative to Apache's logrotate, there is multilog from djb's daemontools package - ports/sysutils/daemontools, http://cr.yp.to/daemontools.html Anything DJB has written is a last resort, not an alternative. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
netgraph arp issues vs linux veth
I made another attempt with netgraph and I think I'm almost there, but I'm still having some issues. I found a linux solution called veth http://www.geocities.com/nestorjpg/veth/ which might do the job, but I would prefer to use netgraph if possible. Here is some more detailed config information. I ran this on the spoof machine # ngctl mkpeer . eiface hook ether # ifconfig ngeth0 link 00:bd:03:12:12:12 # ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 # ngctl mkpeer ngeth0: bridge lower link0 # ngctl name ngeth0:lower broken # ngctl connect fxp0: broken: lower link1 # ngctl connect fxp0: broken: upper link2 # ngctl connect ngeth0: broken: upper link3 # ngctl msg ngeth0: setpromisc 1 # ngctl msg ngeth0: setautosrc 0 # ngctl msg fxp0: setpromisc 1 # ngctl msg fxp0: setautosrc 0 # ngctl show broken: Name: broken Type: bridge ID: 0046 Num hooks: 4 Local hook Peer name Peer typePeer ID Peer hook -- - ---- - link3 ngeth0 ether0005upper link2 fxp0ether0004upper link1 fxp0ether0004lower link0 ngeth0 ether0005lower on the remote machine an arp -a lists this ? (192.168.10.3) at 00:bd:03:12:12:12 on rl0 [ethernet] ? (192.168.10.1) at 00:00:e8:5b:13:44 on rl0 permanent [ethernet] on the spoof machine an arp -a lists this ? (192.168.10.1) at (incomplete) on ngeth0 [ethernet] ? (192.168.10.3) at 00:bd:03:12:12:12 on ngeth0 permanent [ethernet] a sniff on the spoof machine listed this while pinging the remote machine # tcpdump -i ngeth0 'ether host 00:00:e8:5b:13:44' tcpdump: listening on ngeth0 14:03:30.519263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:03:33.416568 192.168.10.1 192.168.10.3: icmp: echo request 14:03:40.530562 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:03:43.427175 192.168.10.1 192.168.10.3: icmp: echo request 14:03:50.540805 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:03:53.437845 192.168.10.1 192.168.10.3: icmp: echo request 14:04:00.550960 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:04:03.448383 192.168.10.1 192.168.10.3: icmp: echo request a sniff on the remote machine listed this while pinging the spoof machine # tcpdump -i rl0 'ether host 00:bd:03:12:12:12' tcpdump: listening on rl0 14:02:24.918804 192.168.10.1 192.168.10.3: icmp: echo request 14:02:29.179263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:02:34.929051 192.168.10.1 192.168.10.3: icmp: echo request 14:02:44.939136 192.168.10.1 192.168.10.3: icmp: echo request 14:02:52.052260 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:02:54.949402 192.168.10.1 192.168.10.3: icmp: echo request 14:03:02.063079 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 14:03:04.959534 192.168.10.1 192.168.10.3: icmp: echo request 14:03:12.072830 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 Any clues or pointers are greatly appreciated and will mean I get to deploy FreeBSD with netgraph rather than linux with veth. Regards, David Yeske ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
plot.thickness++ (Re: Core dump with tip (ucom0 - external modem))
I got an interesting clue by trying ECU. Check this out: ECU is a dialer type program. I told it to use /dev/ucom0 to dial my desk phone number, and it showed itself trying to issue a bunch of commands to the modem, but each time they came back and said missed expected carriage return. It eventually gave up, but my phone then started ringing! Dialing telno 23645 on /dev/ucom0 at 9600 baud (10:24:25) Trying ecu dialer /usr/local/lib/ecu/ucom0.mi: No such file or directory modem init string not found (using default 'ATE1Q0V1') modem dial string not found (using default 'ATDT') ATE1Q0V1 missed expected carriage return got nothing ATE1Q0V1 missed expected carriage return got nothing ATE1Q0V1 missed expected carriage return got nothing ATE1Q0V1 missed expected carriage return got nothing /usr/local/lib/ecu/ucom0.mi: No such file or directory modem init string not found (using default 'ATE1Q0V1') modem dial string not found (using default 'ATDT') ATE1Q0V1 missed expected carriage return got nothing ATE1Q0V1 missed expected carriage return got nothing ATE1Q0V1 missed expected carriage return got nothing ATE1Q0V1 missed expected carriage return got nothing ATDT23645 missed expected carriage return Cannot talk to modem When it was over, I did a tip on the same device and it spewed a bunch of garbage at me: OK AT OK ATQ0V1E1 OK ATE1Q0V1 OK AT OK ATQ0V1E1 OK ATE1Q0V1 OK AT OK ATQ0V1E1 OK ATE1Q0V1 OK ATE1Q0V1 OK AT OK ATQ0V1E1 OK ATE1Q0V1 OK AT OK ATQ0V1E1 OK ATE1Q0V1 OK AT OK ATQ0V1E1 OK ATE1Q0 So all the commands were going through, but somehow being buffered...? Any knobs I can play with to help with this situation? Thanks, Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Loosing STDOUT after file rotation
DJB's code, a last resort? I surely wouldn't refer to all of it as a last resort, not in the least. To each his own - of course. Although I certainly think you're belittling someone with plenty of skill. Do you regard Qmail as a last resort MTA? I'd have to disagree strongly there. -mpf Dag-Erling Smørgrav wrote: Peter Pentchev [EMAIL PROTECTED] writes: Or, as an alternative to Apache's logrotate, there is multilog from djb's daemontools package - ports/sysutils/daemontools, http://cr.yp.to/daemontools.html Anything DJB has written is a last resort, not an alternative. DES ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Loosing STDOUT after file rotation
Peter Pentchev [EMAIL PROTECTED] writes: Anything DJB has written is a last resort, not an alternative. DES Are you speaking with regard to the code or the license? If the code, what are your reasons for saying this? If the license, nevermind. -- Shawn ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Loosing STDOUT after file rotation
Anything DJB has written is a last resort, not an alternative. DES Shawn Harrison wrote: Are you speaking with regard to the code or the license? If the code, what are your reasons for saying this? If the license, nevermind. I'm not DES, but I have a couple of examples in qmail 1.03 of code problems. If I had any expectation that djb would update qmail, I would address these to him instead of to you and to individuals I SMTP with who use qmail. 1. qmail violates SMTP RFCs in the name of being picky about line endings in SMTP DATA. I saw it operating a different MTA as backup MX for someone using qmail on their primary inbound MX. Someone dropped off some spam on my MTA which had a bare LF in qmail parlance, which may be a problem in that legitimate SMTP line endings are required to pair CR and LF. My MTA attempted to deliver the mail to the primary MX for the domain in question, triggering qmail's poorly coded bare LF check, which writes a 451 temporary failure response with a pointer to a djb web page shaking fingers over line endings: 451 See http://pobox.com/~djb/docs/smtplf.html. However, the SMTP violation comes in here. First of all, the response comes in immediately, not after the CRLF.CRLF termination of the DATA payload. RFC821/STD0010 section 4.4 states regarding DATA payload: Note that the 'data' here here is a series of lines sent from the sender to the receiver with no response expected until the last line is sent. More seriously, qmail then simply terminates the process and thereby closes the SMTP connection, which clearly violates RFCs 821 and 2821, section 4.1.1 on command semantics, which says regarding QUIT: The receiver should not close the transmission channel until it receives and replies to a QUIT command (even if there was an error). The sender should not close the transmission channel until it send a QUIT command and receives the reply (even if there was an error response to a previous command). If the connection is closed prematurely the receiver should act as if a RSET command had been received (canceling any pending transaction, but not undoing any previously completed transaction), the sender should act as if the command or transaction in progress had received a temporary error (4xx). So a standards-compliant MTA sending a bare LF bomb to qmail engages in a race between recognizing the premature 451 response to the DATA command, or noticing the socket has been dropped by the server in violation of spec. Such a sender will in either case treat this as a temporary failure and retry after some interval. If the sender is an innocent backup MX, the resulting behavior is wasteful repeated resending of the bare LF bomb, terminally receiving a hopeful temporary failure. If you use qmail, please consider simply editing out the bare LF check entirely, nothing else goes haywire in the experience of several of my friends. At least for inbound MXes, if not for customer-facing outbound relays. 2. Yes, despite two or three RFC violations above, there's another bone I have to pick with qmail. In today's world of massive worm-infested-sender spam, joe-job spam backscatter, and worm infection attempts via email and their backscatter, it is irresponsible though not violating any RFCs to blindly accept any and all RCPT email addresses @ a domain name qmail handles mail for, only to generate bounce emails later on for mails addressed to non-existent local parts. That is, even though qmail is in a position to know that, say, [EMAIL PROTECTED] is not a valid email address, instead of responding to a RCPT TO:[EMAIL PROTECTED] command with an error, qmail chooses to accept the address and the accompanying mail traffic, then quickly turn around a bounce email message to the purported sender including a copy of the message. Why do I care if qmail is accept-then-bounce instead of refusing to accept the address? Because worms forge my email addresses as purported sender after finding it on someone else's computer. One of my former email addresses ([EMAIL PROTECTED] again) is handled by qmail, and to do my part I'd like to see worm bounces and other wasteful traffic refused before DATA rather than using the bandwidth of the distributed.net mailserver twice over. Similarly, I'd rather see worm attempts to infect [EMAIL PROTECTED] result in the worm failing to send the email in the first place, rather than having it send it successfully only to have distributed.net's mailserver send a helpful bounce to an innocent purported sender (remember, worms lie about sender habitually) containing a copy of the infection vector. I hear wonderful things about Postfix, and my impression is it has a license that won't leave you down a dead-end road like qmail's does. Dave Hart [EMAIL PROTECTED] ___ [EMAIL
