Am Samstag, 19. Februar 2011, um 22:34:03 schrieb ERJAVEC Tom: > Hello Team, > > I'm still playing with 4.0 and here are some more observations from me. I > tried to set up yate on Bering. All went fine until the test from an IP > phone. Shorewall was rejecting packets on 5060, incoming from loc. I added > rules: ACCEPT loc fw tcp 5060 > ACCEPT loc fw udp 5060 > with no success, so just in case I added two more: > ACCEPT fw loc tcp 5060 > ACCEPT fw loc udp 5060 > clearly with no success, too. > Then I desperately opened the policy: > loc fw ACCEPT > with no success, either. > I *think* I was doing those changes through the web interface, saving the > configs and restarting the shorewall. Through phone call testing the > shorewall.log was growing bigger, all packets rejected. The last size I > saw was 82K bytes. To test what was going on I closed ping in the > shorewall rules file, but it kept pinging. OK, my mistake, closed the > policy from loc, it kept pinging. Just like a service restart from the web > interface did not happen. Finally I checked the setup files on the > console, they looked right. I rebooted from command line, went back to the > web interface --- and shorewall.log was gone. Disappeared. After several > reboots I could not bring it back. It is still defined in shorewall.conf, > but not existing. "find / -name shorewall.log" can't find it. > > To even more surprise: I picked the IP phone - and it worked. I get the > "busy" signal from the first yate example. Now I'd like to reproduce it > but I can not follow the shorewall log. :-( Is there some new additional > shorewall magic that I have missed? > Previous shorewalls behaved very predictably to me. > (I may not reply next week - will be mostly offline).
Maybe it's too late for me - but: 1) What exactly is your problem? 2) Please don't mix web interface and CLI during testing - it will make it easier to track down the pb's. kp ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
