Created attachment 3376 [details] report.bug.xz After a Mga3beta2 LXDE install, and then installing ipw2200, the network is up, but it is impossible to use the connection. journalctl shows a lot of the same messages: Jan 15 18:49:56 DenkBlok kernel: Shorewall:OUTPUT:REJECT:IN= OUT=eth1 SRC=192.168.1.140 DST=10.0.0.199 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=2963 SEQ=1 In MCC drakfirewall, to my surprise "Everything (no firewall)" is selected. After removing the tick there, and selecting to have the firewall for both network cards, WLAN functions as it should. However, looking again afterwards, "Everything (no firewall)" is ticked again! I'm filing against installer, but I'm not sure it was a default setting while installing that caused this, or just a bug in drakfirewall or somewhere else.
assigning to tv @ colin If you think this has nothing to do with installer or drakfirewall, please say so
CC: (none) => mageiaAssignee: bugsquad => thierry.vignaudWhiteboard: (none) => 3beta2
wrong package
Assignee: thierry.vignaud => mageiaSource RPM: drakx-installer-stage2, drakfirewall => drakx-net
(In reply to comment #2) > wrong package ah, if drakx-net is the culprit: All my neighbours seemed to have changed their SSIDs, and instead of the Mac-address of our accesspoint, I saw some signs and letters, maybe like this: \O_\O_
See also bug 7676
(In reply to comment #4) > See also bug 7676 Ah, I thought that couldn't be the same bug, because I didn't hit it with a cauldron boot.iso install later. Besides: With 3beta2, I did get an ip address, so I did get connected. However, you're first in queue to have your bug fixed :-D > instead of the Mac-address of our accesspoint, I saw some signs and letters, > maybe like this: \O_\O_ That was (and is): \x00\x00 (so far for my memory :/ ) After a fresh start, WLAN is still usable :)
Priority: Normal => release_blocker
Blocks: (none) => 8770
Blocks: (none) => 8700
Please open another bug for the \x00 thing, it looks like a separate issue.
http://svnweb.mageia.org/soft/drakx-net/trunk/lib/network/shorewall.pm?revision=3607&view=markup#l111 /etc/rc3.d/S*shorewall no longer exist in cauldron this patch https://abf.rosalinux.ru/soft/drakx-net/commit/64b47b9b2aaca4b72a50f4dfdcfec4b3014af5c0#diff-2 from from rosa make drakfirewall working again I don't know if it will fix other shorewall installer bugs (ie not enable as default)
Keywords: (none) => PATCHCC: (none) => thierry.vignaud
(In reply to comment #6) > Please open another bug for the \x00 thing, it looks like a separate issue. I was just about to do that, but then I saw bug 8942 is already about \x00\x00\x00\x00\x00 I'll comment there.
*** Bug 9125 has been marked as a duplicate of this bug. ***
CC: (none) => gruescubogdan
(In reply to comment #7) Ouch :-( ! Fixed in SVN Thx for spotting this...
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Now, when I try to configure the firewall, drakfirewall crashes. Here is the message I get: The "drakfirewall" program has crashed with the following error: Undefined subroutine &services::is_service_running called at /usr/lib/libDrakX/network/shorewall.pm line 115. Perl's trace: standalone::bug_handler() called from /usr/lib/libDrakX/network/shorewall.pm:115 network::shorewall::read() called from /usr/lib/libDrakX/network/drakfirewall.pm:219 network::drakfirewall::get_conf() called from /usr/lib/libDrakX/network/drakfirewall.pm:333 network::drakfirewall::main() called from /usr/sbin/drakfirewall:32
CC: (none) => periliocastrol
have you a 'require services' in the file /usr/lib/libDrakX/network/shorewall.pm ?
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
ok, it was missing, coming updates should fix it http://svnweb.mageia.org/soft/drakx-net/trunk/lib/network/shorewall.pm?r1=7340&r2=7348
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
This fix was broken in multiple ways: - the check was inverted (it was ok in the initial Rosa patch though) - quotes were missing around the "shorewall" service name - it checks if shorewall is running, which it should check if the service is enabled (this should work better during installer) I have updated the fix in r7657