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).

Cheers, Tom

------------------------------------------------------------------------------
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/

Reply via email to