Custom Query (115 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (22 - 24 of 115)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Resolution Summary Owner Reporter
#125 invalid Apply Changes does not fully work. Victor Julien anonymous
Description

Making rule changes, and then selecting "Apply Changes", seems to do something, but rules do not seem "fully" applied. Only after restarting the vuurmuur service do all the changes appear.

Running Vuurmuur_conf 0.7 on both Ubuntu 9.04 and 9.10.

#123 fixed ICMP traffic can kill [segfault] the connection viewer (parser error) Victor Julien photon
Description

managed to crash vuurmuur_conf with a segmentation fault by sending a single ICMP echo request to the server vuurmuur was running on.

[ vuurmur version is the current 0.7 ( from debian unstable ) ]

this is reproducible. (ICMP type 8 however must have an accept rule or the packets will not appear in conntrack.) if there is a ping running and sending packets to the ip it will even segfault the very moment the connection viewer is being opened.

it apparently did not like the format of the ICMP lines in /proc/net/ip_conntrack, which you can see in the appended debug.log output.

i was finetuning a new (2.6.32.2) kernel config and assumed it might have something to do with it. [ however, i just checked the issue on nodes with distro kernels and noticed that they do not show any icmp entries in /proc/net/ip_conntrack so the parser couldn't have run into the string anyway. ]

not sure if it is related but in some (not all) of the cases before the crash the connection viewer printed the following "Internal Error"s:

'Error: parameter problem (in: d_list_remove_node).'

'Error: could not remove node (in: d_list_cleanup:536).'

'Error: cleaning up row 504 failed (in: hash_cleanup).'

[ when that happened and the pings have stopped meanwhile (before closing the error messages), it managed to display the ICMP entry for a second before it got cleaned up. but by sending a new packet it segfaults again. ]

here are the related log entries:

## dmesg output ## ( 'vc' here is a symlink to vuurmuur_conf )

[ 1764.726656] vc[19313]: segfault at 35 ip b76a3152 sp bfc64ea0 error 4 in libvuurmuur.so.0.6.0[b7696000+38000]

# the following 'xxx' bytes in the ip addresses are not in the original log strings ;)

## /var/log/vuurmuur/debug.log ##

12/22/2009 06:40:31 : PID 17269 : vuurmuur_conf : parse_icmp_line: parse error: 'icmp 1 7 src=62.xxx.xxx.xxx dst=188.xx.xxx.xxx type=8 code=0 id=14898 packets=1708 bytes=143472 src=188.xx.xxx.xxx dst=62.xxx.xxx.xxx type=0 code=0 id=14898 packets=1705 bytes=143220 mark=0 secmark=0 use=2 ' 12/22/2009 06:40:31 : PID 17269 : vuurmuur_conf : parse_icmp_line: to dst: 1708P 143472B to src: P B 12/22/2009 06:40:59 : PID 19313 : vuurmuur_conf : parse_icmp_line: parse error: 'icmp 1 29 src=62.xxx.xxx.xxx dst=188.xx.xxx.xxx type=8 code=0 id=39500 packets=1 bytes=84 src=188.xx.xxx.xxx dst=62.xxx.xxx.xxx type=0 code=0 id=39500 packets=1 bytes=84 mark=0 secmark=0 use=2 ' 12/22/2009 06:40:59 : PID 19313 : vuurmuur_conf : parse_icmp_line: to dst: 1P 84B to src: P B

#122 fixed debian init script broken ( s/kill -n /kill -s / ) Victor Julien photon
Description

in the latest debian 'unstable' vuurmuur package (0.7+debian-2) in the file /etc/init.d/vuurmuur there is a typo in the execution of 'kill'.

what is 'kill -n ' should probably be 'kill -s ' ( line {106,117} )

some machines ignore this silently (probably as they try to interpret 'n' as a signal) while others complain and refuse to restart vuurmuur.

it appears to be a copy/paste bug from the lines above ;)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.