Re: ipfw confusion
Are you sure that your DNS requests are over TCP? DNS primarily uses UDP to serve requests. TCP is used when the response data size exceeds 512 bytes (I think), or for tasks such as zone transfers. I know a few resolver implementations use TCP for all queries, but most I have used not. You might want to add rules to allow UDP as well. On Sun, Aug 18, 2013 at 11:06 PM, Gary Aitken wrote: > I'm having some weird ipfw behavior, or it seems weird to me, and am > looking > for an explaination and then a way out. > > ipfw list > ... > 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup > keep-state > 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup > keep-state > ... > 65534 deny log logamount 5 ip from any to any > > tail -f messages > Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error > sending response: permission denied > > 12.32.36.65 is the addr of the internal interface (xl0) on the firewall > and is the public dns server. > 12.32.44.142 is the addr of the external interface (tun0) which is bridged > on a > dsl line. > > It appears that a dns request was allowed in, but the response was not > allowed > back out. It seems to me the above rules 21109 and 21129 should have > allowed > the request in and the response back out. > > It's possible a request could come in on 12.32.44.142, > which is why 21109 is present; > although I know I am getting failures to reply to refresh requests > from a secondary addressed to 12.32.36.65 > > What am I missing? > > Is there a problem if the incoming rule is for tun0, > which gets passed to named > since 12.32.44.142 is on the physical machine running named, > but named pumps its response out on 12.32.36.65, > relying on routing to get it to the right place, > and that fails to match the state tracking mechanism > which started with 12.32.44.142? > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@freebsd.org" > -- Jason Cox ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
AtapiCam Failing on CD Burner
Hello all, Whilew trying to get CD burning working under FreeBSD 6.0 (and 6.1-PreRelease), I keep getting the following error in my dmesg and cd1 is never created. The drive is a Philips CDRW4012P. It shows up as /dev/acd1 and reports correctly in dmesg. However, once atapicam tries to query it, it just repeats the follwoing (output from dmesg with boot -v): ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc acd0: setting PIO4 on ICH5 chip acd0: setting UDMA33 on ICH5 chip acd1: setting PIO4 on ICH5 chip acd1: setting UDMA33 on ICH5 chip ata1: reinit done .. (probe8:ata1:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe8:ata1:0:1:0): CAM Status: SCSI Status Error (probe8:ata1:0:1:0): SCSI Status: Check Condition (probe8:ata1:0:1:0): ILLEGAL REQUEST asc:20,0 (probe8:ata1:0:1:0): Invalid command operation code (probe8:ata1:0:1:0): (probe8:ata1:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe8:ata1:0:1:0): ILLEGAL REQUEST asc:20,0 (probe8:ata1:0:1:0): Invalid command operation code Unretryable error (probe8:ata1:0:1:0): error 22 (probe8:ata1:0:1:0): Unretryable Error I have looked all over the internet and everywhere says it should have been fixed in 4.7. Any advice on what else to try? Jason ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
AtapiCam not recognizing philips cd burner
Hello all, Whilew trying to get CD burning working under FreeBSD 6.0 (and 6.1-PreRelease), I keep getting the following error in my dmesg and cd1 is never created. The drive is a Philips CDRW4012P. It shows up as /dev/acd1 and reports correctly in dmesg. However, once atapicam tries to query it, it just repeats the follwoing (output from dmesg with boot -v): ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc acd0: setting PIO4 on ICH5 chip acd0: setting UDMA33 on ICH5 chip acd1: setting PIO4 on ICH5 chip acd1: setting UDMA33 on ICH5 chip ata1: reinit done .. (probe8:ata1:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe8:ata1:0:1:0): CAM Status: SCSI Status Error (probe8:ata1:0:1:0): SCSI Status: Check Condition (probe8:ata1:0:1:0): ILLEGAL REQUEST asc:20,0 (probe8:ata1:0:1:0): Invalid command operation code (probe8:ata1:0:1:0): (probe8:ata1:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe8:ata1:0:1:0): ILLEGAL REQUEST asc:20,0 (probe8:ata1:0:1:0): Invalid command operation code Unretryable error (probe8:ata1:0:1:0): error 22 (probe8:ata1:0:1:0): Unretryable Error I have looked all over the internet and everywhere says it should have been fixed in 4.7. Any advice on what else to try? Jason ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
