BUT if I hit Ctrl-D in the dtterm window... it understands that and closes the window right out.
That seems to be the only thing its capable of doing, though. -S On 9/29/06, Sean Caron <[EMAIL PROTECTED]> wrote:
Hi Wayne, Thanks for the response! I tried this, but it didn't seem to change anything. I created the lines -- pass in quick from 127.0.0.1 to www.xxx.yyy.zzz port = 111 pass in quick from 127.0.0.1 to www.xxx.yyy.zzz port = 32775 pass in quick from 127.0.0.1 to www.xxx.yyy.zzz port = 32777 pass in quick from 127.0.0.1 to www.xxx.yyy.zzz port = 32779 pass in quick from 127.0.0.1 to www.xxx.yyy.zzz port = 32776 pass in quick from 127.0.0.1 to www.xxx.yyy.zzz port = 32781 and added them to my ipf.conf file along with the lines that were already there -- pass in log on er0 all pass out log on eri0 all pass in log on lo0 all pass out log on lo0 all when that didn't work, I commented out my eri0/lo0 lines and just had the 6 lines that you suggest -- and still the same result. I've had a dtterm sitting here for at least five minutes with no shell invoked yet. Strangely enough, this doesn't affect all dtterm applications equally. The file manager continues to work (thankfully, so I can invoke xterms and poke around) -- but dtterm has always been broken, and the box always hangs on logout. If I truss dtterm, this is what I see at the end when it "hangs" and falls into the sleep loop -- ioctl(4, FIONREAD, 0xFFBFEEE4) = 0 write(4, " B\0\007\090\0 1\090\o\f".., 400) = 400 ioctl(4, FIONREAD, 0xFFBFEEE4) = 0 poll(0xFFBFEC68, 2, -1) (sleeping...) then it just sits. If I click inside the dtterm window, I get a flurry of activity, but it always settles back down with the -- ioctl(4, FIONREAD, 0xFFBFEEE4) = 0 poll(0xFFBFEC68, 2, -1) (sleeping...) perhaps this is helpful to anyone? Regards, Sean On 9/29/06, Wayne Rasmussen <[EMAIL PROTECTED]> wrote: > You may have to test the following ports but try them > 111 > 32775 > 32777 > 32779 > 32776 > 32781 > > with a line like (your server IP is 1.1.1.12) for each port. You need > the rpc lines. > pass in quick from 127.0.0.1 to 1.1.1.12 port = 111 > > If this works, then you can removed one at a time until you find the > ones you need. > > -----Original Message----- > From: Sean Caron [mailto:[EMAIL PROTECTED] > Sent: Friday, September 29, 2006 11:06 AM > To: [email protected] > Subject: IPFilter breaks CDE? > > Hi all -- > > I've been encountering some strange problems with ipfilter and I think > that I am just about at the end of my rope -- not sure what to try > now! I was hoping people here could perhaps give some hints. > > The situation -- my boss has me putting together a new Solaris 9 load > for the few Sun machines we still have left around these place. He's > quite infatuated with host based firewalls in general and insists that > we have ipfilter on our new load. OK, so... > > I have a stock Solaris 9 load circa September 2004 > > I install the latest patch cluster you can get from sun.com (or not; > it doesn't make a difference either way) > > Install our AFS and Kerberos clients (not really applicable, but I'll > mention it for completeness) > > So, then, what I have done is this -- I downloaded pfil 2.1.11 and > ip_filter 4.1.13. I built the two programs on another Solaris 9 system > that we have online here. Getting them to build was a bit of an > adventure but I did get them to both build successfully. > > I couldn't get the various 'make package' type functions to work so I > just created my own packages manually by constructing the directory > tree given in the package definition file manually, then making a > tarball out of it. I save the post-install scripts that are supposed > to run when the package is installed and run those manually too. > > So, it all seems to be configured normally. The kernel modules load > right up with no trouble at all. All the programs (ipf, ipfs, ipfstat, > etc) run normally -- I don't see any errors about missing libraries or > any other similar nonsense when I run them. > > The problem is -- as soon as I install ipfilter, the machine starts > acting quite wierd. If you use CDE as your X environment, a lot of > stuff breaks. One of the most prominent examples of this is dtterm. If > you invoke dtterm, it fires up, but you just get a blank screen with > the cursor blinking in the corner; the shell never starts up. If you > try and log out, you just get a white screen, and the system hangs -- > you have to Stop-A to get anywhere after that point AFAIK. > > If you use GNOME instead, the terminal works fine. In fact, xterm > works fine too. It is just dtterm that gets broken. But logging out is > always broken, regardless of if you use CDE or GNOME. > > I feel like ipfilter is getting in the way of X somehow and confusing > it? But that doesn't really make a lot of sense to me, especially when > ipf.conf looks like this -- > > pass in log on eri0 all > pass out log on eri0 all > pass in log on lo0 all > pass out log on lo0 all > > and I have used ipfilter on, say, NetBSD quite a bit (of course, since > it is included) and have never seen any of these sorts of problems > there. > > If i ktruss dtterm or something like that, it seems to be getting into > some loop where it tries to do something, goes to sleep for a while, > tries again, ad nauseum. It isn't really "locked up" per se; you can > close out the hung dtterm just fine by clicking the close button in > the corner. > > Any ideas? Anyone ever seen this sort of behaviour before? If more > data is needed, please let me know and I'll get whatever is needed > right away. I can't seem to find much about this at all searching the > Web. > > Thanks in advance for any help, > > Sean Caron >
