ipcop-devel Mailing List for IPCop Firewall

Bugs item #2942341, was opened at 2010-01-29 08:22
Message generated for change (Tracker Item Submitted) made by mstiner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2942341&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: mstiner (mstiner)
Assigned to: Nobody/Anonymous (nobody)
Summary: IPCop beta vs 1.9.11 drops into 'Resque Mode'

Initial Comment:
I have a Dell PowerEdge R210 Server with a sata DVD and a sata HD. The chipset is an Intel 3420.

I can install IPCop vs 1.9.11 without error.  
My problem starts when IPCop tries to load; Directly after the message "Running in Normal Mode" IPCop displays the following message:

wating for /dev/disk/by-label/root ............failed
Running in resque mode

BusyBox v1.14.4 (2010-01-21 14:56:20 GMT) built in shell (ash)
Enter 'help' for a list of built-in commands.

Cannot open font file lat0-16
(resque-i686):/$

## any help would be greatly appreciated.
Thank you,

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2942341&group_id=40604

Guenter wrote:

> I think this would be the right way to go since then there would be no
> need for the user to modify /etc/usb_modeswitch.conf; in fact it would
> be obsolete then. So we should look into:

I don't think so. To me the easiest way looks like this:
use the /etc/usb_modeswitch.d directory from upstream, remove all device
rules from udev/usb_modeswitch.rules and have only one line containing
RUN+="/usr/sbin/usb_modeswitch.pl '%b/%k'" (or something like that), and
rewrite the tcl script from upstream in perl.

We'd only need to add new files in /etc/usb_modeswitch.d as and when
they become available.

Something like that I will also suggest to upstream, the current method
with having device information in 3 places (.conf, directory and udev
rule) looks too much.

The only thing left for the user is to 'activate' usbserial (or any of
the other kernel drivers) via modules/modprobe.d config files.


Olaf

All,
I got finally the kernel modules ledtrig-morse and ledtrig-netdev 
compiled; ledtrig-netdev is very useful for showing network traffic of 
RED / BLUE / GREEN interfaces ...
here's an archive with these trigger modules currently missing with 1.9.11:
http://www.gknw.net/test/ipcop/ledtrig-mods-2.6.27-3.tar.gz
the archive also contains an updated rc.event.local and a testscript 
ledcontrol, also a README with samples in German (mostly).

Olaf, can you please add this patch so that these two modules get 
included with next version?
http://www.gknw.net/test/ipcop/linux-2.6.27-ledtrig-morse+netdev.patch.txt

Eric, can you perhaps create a Wiki page with this topic, and take the 
README from the archive mentioned above as basis? Also I think the 
rc.event.local should be included into this page as sample ...
such script hacking is not every user's thing ...

thanks, Gün.

Guenter schrieb:
> 2. add comgt to Ipcop since it seems a small useful tool for checking
> with the UMTS device like signal strength, registered networks, default
> APN, and also for switching modes, or unlocking the SIM with the PIN if
> enabled.
> http://surfnet.dl.sourceforge.net/project/comgt/comgt/0.32/comgt.0.32.tgz
> here's a compiled version on my site:
> http://www.gknw.net/test/ipcop/comgt-ipcop-1.9.x.tar.gz
It's necessary to include this patch unless we get a 0.33 version:
http://sourceforge.net/tracker/?func=detail&aid=1610044&group_id=174961&atid=871315
on order to set the APN with the internal script.
I've updated the binary on my site with the patched version:
http://www.gknw.net/test/ipcop/comgt-0.32p-ipcop-1.9.x.tar.gz

Gün.

Hi Olaf,
answering myself .....
Guenter schrieb:
> Now I would like to know how I can make udev take care of the
> usb_modeswitch and loading usbserial after a reboot?
> Olaf, maybe you can kindly post a udev rule for this? Or how is it done
> correctly? I guess modifying usb_modeswitch.conf is the wrong way, or?
ok - from what I see it *is* currently the right way, and the
usb_modeswitch,sh does only call usb_modeswitch without params which
means whats in /etc/usb_modeswitch.conf will be used ...

I digged some more, and tested a bit on my SuSE 11.1 box; I created
there a file /etc/udev/rules.d/51-huawei.rules with content:
# Huawei K3765
BUS=="usb", SYSFS{idVendor}=="12d1",SYSFS{idProduct}=="1520",
RUN+="/usr/sbin/usb_modeswitch -v 0x%s{idVendor} -p 0x%s{idProduct} -m
0x01 -M 55534243123456780000000000000011060000000000000000000000000000"
ACTION=="add", SUBSYSTEM=="usb",
ATTR{idVendor}=="12d1",ATTR{idProduct}=="1465",RUN+="/sbin/modprobe
usbserial vendor=0x%s{idVendor} product=0x%s{idProduct}"

and this works fine; when I plug in the stick then the rule bites,
switches the device and finally loads usbserial so that the K3765 is usable.
Then I tried same on Ipcop:
--- /etc/udev/rules.d/80-usb_modeswitch.rules.orig	2010-01-14
02:47:00.000000000 +0100
+++ /etc/udev/rules.d/80-usb_modeswitch.rules	2010-01-24
19:26:54.000000000 +0100
@@ -195,7 +195,8 @@
 SYSFS{idVendor}=="12d1", SYSFS{idProduct}=="1446",
RUN+="/usr/sbin/usb_modeswitch.sh '%b/%k'"

 # Huawei K3765
-SYSFS{idVendor}=="12d1", SYSFS{idProduct}=="1520",
RUN+="/usr/sbin/usb_modeswitch.sh '%b/%k'"
+SYSFS{idVendor}=="12d1", SYSFS{idProduct}=="1520",
RUN+="/usr/sbin/usb_modeswitch -Q -I -v 0x%s{idVendor} -p
0x%s{idProduct} -V 0x%s{idVendor} -P 0x1465 -m 0x01 -M
55534243123456780000000000000011060000000000000000000000000000"
+ACTION=="add", SUBSYSTEM=="usb",
ATTR{idVendor}=="12d1",ATTR{idProduct}=="1465",RUN+="/sbin/modprobe
usbserial vendor=0x%s{idVendor} product=0x%s{idProduct}"

 # Huawei K4505
 SYSFS{idVendor}=="12d1", SYSFS{idProduct}=="1521",
RUN+="/usr/sbin/usb_modeswitch.sh '%b/%k'"

but seems that somehow the vars dont work same way as usual, nor works
the ACTION stuff; so after some trial&error runs I found this working
for me:
--- /etc/udev/rules.d/80-usb_modeswitch.rules.orig	2010-01-14
02:47:00.000000000 +0100
+++ /etc/udev/rules.d/80-usb_modeswitch.rules	2010-01-24
20:34:28.000000000 +0100
@@ -195,7 +195,8 @@
 SYSFS{idVendor}=="12d1", SYSFS{idProduct}=="1446",
RUN+="/usr/sbin/usb_modeswitch.sh '%b/%k'"

 # Huawei K3765
-SYSFS{idVendor}=="12d1", SYSFS{idProduct}=="1520",
RUN+="/usr/sbin/usb_modeswitch.sh '%b/%k'"
+SYSFS{idVendor}=="12d1", SYSFS{idProduct}=="1520",
RUN+="/usr/sbin/usb_modeswitch -Q -I -v 0x12d1 -p 0x1520 -V 0x12d1 -P
0x1465 -m 0x01 -M
55534243123456780000000000000011060000000000000000000000000000"
+SYSFS{idVendor}=="12d1", SYSFS{idProduct}=="1465", RUN+="/sbin/modprobe
usbserial vendor=0x12d1 product=0x1465"

 # Huawei K4505
 SYSFS{idVendor}=="12d1", SYSFS{idProduct}=="1521",
RUN+="/usr/sbin/usb_modeswitch.sh '%b/%k'"

I think this would be the right way to go since then there would be no
need for the user to modify /etc/usb_modeswitch.conf; in fact it would
be obsolete then. So we should look into:
1. rewrite /etc/udev/rules.d/80-usb_modeswitch.rules completely in the
way I suggested above for the K3765; I mean here either ask for a
volunteer who does it, or better hack a script which does the job of
reading /etc/usb_modeswitch.conf contents, and write out proper udev
rules for all listed devices to /etc/udev/rules.d/80-usb_modeswitch.rules.
2. add comgt to Ipcop since it seems a small useful tool for checking
with the UMTS device like signal strength, registered networks, default
APN, and also for switching modes, or unlocking the SIM with the PIN if
enabled.
http://surfnet.dl.sourceforge.net/project/comgt/comgt/0.32/comgt.0.32.tgz
here's a compiled version on my site:
http://www.gknw.net/test/ipcop/comgt-ipcop-1.9.x.tar.gz

Gün.

On 23 January 2010 18:26, Guenter <li...@gk...> wrote:
> Eric,
> Eric Oberlander schrieb:
>>> The vmlinuz symlink is modified in the upgrade. Note that it is not
>>> important, at least not for i486, since the boot selection does not use it.
>>> I was tempted to remove it, but left it for alpha and ppc, as I am not
>>> sure if those will work when using 'long' vmlinuz filenames.
>>>
>>> The System.map symlink is set/adjusted in rc.sysinit.
>>>
>>> When booting check the 'line' which is active in the bootmenu, could
>>> well be that the 'default' extlinux selection is playing some kind of trick.
>>>
>>> Olaf
>>
>> OK, I'm running a headless box, so I'll have to add a keyboard and
>> monitor to check and report back after a reboot in due course.
> no need - just
> vi /boot/extlinux.conf
> and remove the second 'MENU default' line below 'LABEL old-ipcop'
> reboot and you should be on -3 kernel.

Vielen Dank

Eric

Eric,
Eric Oberlander schrieb:
>> The vmlinuz symlink is modified in the upgrade. Note that it is not
>> important, at least not for i486, since the boot selection does not use it.
>> I was tempted to remove it, but left it for alpha and ppc, as I am not
>> sure if those will work when using 'long' vmlinuz filenames.
>>
>> The System.map symlink is set/adjusted in rc.sysinit.
>>
>> When booting check the 'line' which is active in the bootmenu, could
>> well be that the 'default' extlinux selection is playing some kind of trick.
>>
>> Olaf
> 
> OK, I'm running a headless box, so I'll have to add a keyboard and
> monitor to check and report back after a reboot in due course.
no need - just
vi /boot/extlinux.conf
and remove the second 'MENU default' line below 'LABEL old-ipcop'
reboot and you should be on -3 kernel.

BTW. what about enabling the serial line? Then you could also watch teh
boot process ....

Gün.

Olaf,
Guenter schrieb:
> Olaf Westrik schrieb:
>> When booting check the 'line' which is active in the bootmenu, could
>> well be that the 'default' extlinux selection is playing some kind of trick.
> that's the rpoblem: we have *two* default sections! First the have the
> new entries with the -3 kernel, but *after* that there are the -old
> entries pointing to the -2 kernel; and I assume that the last entry wins
> which is then the -2 one ...
> What speaks against using symlinks for initrd and the kernel too? This
> way there would be no need to change extlinux.conf at all - instead only
> fix the symlinks with the update, and all fine ...
after removing the second default line from extlinux.conf the box now
boots into -3 kernel.

Gün.

Guenter wrote:
> Hi Olaf,
> Olaf Westrik schrieb:
>> When booting check the 'line' which is active in the bootmenu, could
>> well be that the 'default' extlinux selection is playing some kind of trick.
> that's the rpoblem: we have *two* default sections! First the have the
> new entries with the -3 kernel, but *after* that there are the -old
> entries pointing to the -2 kernel; and I assume that the last entry wins
> which is then the -2 one ...

Yes. Simple fix, remove 1 line (that should not be there anyway) in
updatekernel.pl and the problem will not be present for future updates.

For those that have upgraded and have never used the extlinux boot menu:
remove the line MENU default below LABEL old-ipcop in
/boot/extlinux.conf and all is well.


> What speaks against using symlinks for initrd and the kernel too? This
> way there would be no need to change extlinux.conf at all - instead only
> fix the symlinks with the update, and all fine ...

That case you will not be able to boot the old kernel.
Now I don't care that much for old kernels, but there are people who
feel very strongly about that.


Olaf

Hi Olaf,
Olaf Westrik schrieb:
> When booting check the 'line' which is active in the bootmenu, could
> well be that the 'default' extlinux selection is playing some kind of trick.
that's the rpoblem: we have *two* default sections! First the have the
new entries with the -3 kernel, but *after* that there are the -old
entries pointing to the -2 kernel; and I assume that the last entry wins
which is then the -2 one ...
What speaks against using symlinks for initrd and the kernel too? This
way there would be no need to change extlinux.conf at all - instead only
fix the symlinks with the update, and all fine ...

Gün.

Eric Oberlander wrote:
>> I've tested both the update and a fresh iso installation, and see a
>> difference: the fresh install comes up with kernel 2.6.27-3 while the
>> updated one stays at 2.6.27-2 ...
>>
>> Gün.
> 
> I can confirm that. After updating my system thinks it is still 2.6.27-2.
> 
> It looks like a broken link in /boot
> 
> -rw-r--r--  1 root root    1801 2009-12-16 10:15 extlinux.conf
> -r--r--r--  1 root root   14336 2009-11-21 15:16 extlinux.sys
> -rw-r--r--  1 root root 3649257 2009-11-21 15:16 ipcoprd-2.6.27-2.img
> -rw-r--r--  1 root root 4038053 2010-01-21 20:23 ipcoprd-2.6.27-3.img
> -rw-r--r--  1 root root     440 2009-11-20 15:07 mbr.bin
> -rwxr-xr-x  1 root root  156184 2010-01-21 14:54 memtest
> -rw-r--r--  1 root root  166515 2009-11-20 15:07 splash.png
> lrwxrwxrwx  1 root root      19 2009-11-21 15:13 System.map ->
> System.map-2.6.27-2
> -rw-r--r--  1 root root  857947 2009-11-20 14:10 System.map-2.6.27-2
> -rw-r--r--  1 root root  857947 2010-01-21 14:22 System.map-2.6.27-3
> -rw-r--r--  1 root root  156944 2009-11-20 15:07 vesamenu.c32
> lrwxrwxrwx  1 root root      16 2010-01-21 20:20 vmlinuz -> vmlinuz-2.6.27-3
> -rw-r--r--  1 root root 1121984 2009-11-20 14:10 vmlinuz-2.6.27-2
> -rw-r--r--  1 root root 1121792 2010-01-21 14:22 vmlinuz-2.6.27-3
> root@ipcop-199:/boot #
> 
> Note that System.map -> System.map-2.6.27-2 while vmlinuz -> vmlinuz-2.6.27-3

The vmlinuz symlink is modified in the upgrade. Note that it is not
important, at least not for i486, since the boot selection does not use it.
I was tempted to remove it, but left it for alpha and ppc, as I am not
sure if those will work when using 'long' vmlinuz filenames.

The System.map symlink is set/adjusted in rc.sysinit.

When booting check the 'line' which is active in the bootmenu, could
well be that the 'default' extlinux selection is playing some kind of trick.


Olaf

> The vmlinuz symlink is modified in the upgrade. Note that it is not
> important, at least not for i486, since the boot selection does not use it.
> I was tempted to remove it, but left it for alpha and ppc, as I am not
> sure if those will work when using 'long' vmlinuz filenames.
>
> The System.map symlink is set/adjusted in rc.sysinit.
>
> When booting check the 'line' which is active in the bootmenu, could
> well be that the 'default' extlinux selection is playing some kind of trick.
>
> Olaf

OK, I'm running a headless box, so I'll have to add a keyboard and
monitor to check and report back after a reboot in due course.

Eric

> I've tested both the update and a fresh iso installation, and see a
> difference: the fresh install comes up with kernel 2.6.27-3 while the
> updated one stays at 2.6.27-2 ...
>
> Gün.

I can confirm that. After updating my system thinks it is still 2.6.27-2.

It looks like a broken link in /boot

-rw-r--r--  1 root root    1801 2009-12-16 10:15 extlinux.conf
-r--r--r--  1 root root   14336 2009-11-21 15:16 extlinux.sys
-rw-r--r--  1 root root 3649257 2009-11-21 15:16 ipcoprd-2.6.27-2.img
-rw-r--r--  1 root root 4038053 2010-01-21 20:23 ipcoprd-2.6.27-3.img
-rw-r--r--  1 root root     440 2009-11-20 15:07 mbr.bin
-rwxr-xr-x  1 root root  156184 2010-01-21 14:54 memtest
-rw-r--r--  1 root root  166515 2009-11-20 15:07 splash.png
lrwxrwxrwx  1 root root      19 2009-11-21 15:13 System.map ->
System.map-2.6.27-2
-rw-r--r--  1 root root  857947 2009-11-20 14:10 System.map-2.6.27-2
-rw-r--r--  1 root root  857947 2010-01-21 14:22 System.map-2.6.27-3
-rw-r--r--  1 root root  156944 2009-11-20 15:07 vesamenu.c32
lrwxrwxrwx  1 root root      16 2010-01-21 20:20 vmlinuz -> vmlinuz-2.6.27-3
-rw-r--r--  1 root root 1121984 2009-11-20 14:10 vmlinuz-2.6.27-2
-rw-r--r--  1 root root 1121792 2010-01-21 14:22 vmlinuz-2.6.27-3
root@ipcop-199:/boot #

Note that System.map -> System.map-2.6.27-2 while vmlinuz -> vmlinuz-2.6.27-3

Eric

Hi Olaf,
Olaf Westrik schrieb:
> as we speak the final files for testing IPCop on x86 machines are making
> their way to SourceForge. Which, by the way, will take 2-3 hours due to
> my slow connection speed.
> Many minor and some larger things were changed, fixed, etc ...
> 
> With this beta version you will find many things working and some not
> working.
> The largest obstacle at the moment probably being IPsec Roadwarrior.
> 
> Note that this very likely will not be the latest beta version. I expect
> at least 2 or 3 more betas before we go into Release Candidate mode.
> 
> 
> Happy testing ...
I've tested both the update and a fresh iso installation, and see a
difference: the fresh install comes up with kernel 2.6.27-3 while the
updated one stays at 2.6.27-2 ...

Gün.

Guenter wrote:

> I added a section to /etc/usb_modeswitch.conf which enables switching of
> this device:
> --- usb_modeswitch.conf.orig    2010-01-14 02:47:00.000000000 +0100
> +++ usb_modeswitch.conf 2010-01-21 19:53:42.000000000 +0100
> @@ -445,6 +445,25 @@
> 
> 
>  ########################################################
> +# Huawei K3765
> +#
> +# Contributor: Guenter Knauf
> +
> +DefaultVendor=  0x12d1
> +DefaultProduct= 0x1520
> +
> +TargetVendor=   0x12d1
> +TargetProduct=  0x1465
> +
> +# choose one of these:
> +;DetachStorageOnly=1
> +;HuaweiMode=1
> +
> +MessageEndpoint=0x01
> +MessageContent="55534243123456780000000000000011060000000000000000000000000000"
> +
> +
> +########################################################
>  # Huawei E630
>  #
>  # There seem to be modem-only variants around - no storage,


That section already exists in usb_modeswitch 1.07 and thus in IPCop 1.9.11?
You just need to remove the ; commentmarks.


> then loaded usbserial:
> modprobe usbserial vendor=0x12d1 product=0x1465
> 
> and hacked a script to unlock the SIM (not perfect, but works):
> #!/bin/sh
> # Hack to unlock SIM with UMTS cards.

Would that script not block? For example when attempting read from the
wrong ttyUSB* device?
comgt might be a better solution, but I have not tried it.
If comgt could fully replace chat (for all types of modems, not just 3G)
that would be ideal.


> Now I would like to know how I can make udev take care of the
> usb_modeswitch and loading usbserial after a reboot?
> Olaf, maybe you can kindly post a udev rule for this? Or how is it done
> correctly? I guess modifying usb_modeswitch.conf is the wrong way, or?

usb_modeswitch.conf is the right way (for us, for now).

Once the .conf is modified to have your device 'active', it should be
picked up through /etc/udev/rules.d/80-usb_modeswitch.rules
A udev rule for 0x12d1:0x1520 is already there.
Watch /var/log/messages, it should have a usb_modeswitch line.


The easiest way (I think) to add usbserial would be to add usbserial to
/etc/modules.
And add following to /etc/modprobe.d/local.conf:
options usbserial vendor=0x12d1 product=0x1465


Olaf

Hi,
Olaf Westrik schrieb:
> Check this: http://www.speedtest.net/result/679938129.png
> 
> I may need to go ahead and start experimenting with IPCop location.
> Doing tests at 4am is not a real option for me at the moment ;-)
ok, since the PCMCIA Option card seems not an option :( at the moment, I
went ahead, updated to today's 1.9.11, and checked further with my
Huawei USB stick K3765 on my Alix box ...

I added a section to /etc/usb_modeswitch.conf which enables switching of
this device:
--- usb_modeswitch.conf.orig    2010-01-14 02:47:00.000000000 +0100
+++ usb_modeswitch.conf 2010-01-21 19:53:42.000000000 +0100
@@ -445,6 +445,25 @@


 ########################################################
+# Huawei K3765
+#
+# Contributor: Guenter Knauf
+
+DefaultVendor=  0x12d1
+DefaultProduct= 0x1520
+
+TargetVendor=   0x12d1
+TargetProduct=  0x1465
+
+# choose one of these:
+;DetachStorageOnly=1
+;HuaweiMode=1
+
+MessageEndpoint=0x01
+MessageContent="55534243123456780000000000000011060000000000000000000000000000"
+
+
+########################################################
 # Huawei E630
 #
 # There seem to be modem-only variants around - no storage,

then loaded usbserial:
modprobe usbserial vendor=0x12d1 product=0x1465

and hacked a script to unlock the SIM (not perfect, but works):
#!/bin/sh
# Hack to unlock SIM with UMTS cards.

simpin="1234"
device="/dev/ttyUSB0"

exec 3<>${device}

echo "AT+CPIN?" >&3
while [ "$response" != "OK" -a "$response" != "ERROR" ]; do
  read response <&3
  if [ "$response" == "+CPIN: SIM PIN" ]; then
    needpin=1
  elif [ "$response" == "+CPIN: READY" ]; then
    needpin=2
  fi
done

if [ "$needpin" == 1 ]; then
  echo "PIN required! Trying to unlock SIM ..."
  echo "AT+CPIN=${simpin}" >&3
  while [ "$response" != "OK" ]; do
    read response <&3
  done
  echo "AT+CPIN?" >&3
  while [ "$response" != "OK" -a "$response" != "ERROR" ]; do
    read response <&3
    if [ "$response" == "+CPIN: SIM PIN" ]; then
      echo "PIN still required - unlock failed! (wrong PIN?)"
    elif [ "$response" == "+CPIN: READY" ]; then
      echo "SIM unlocked!"
    elif [ "$response" == "ERROR" ]; then
      echo "SIM status check failed!"
    fi
  done
elif [ "$needpin" == 2 ]; then
  echo "SIM unlocked!"
else
  echo "SIM status check failed!"
fi

exec 3>&-

and finally got connected:
http://www.speedtest.net/result/690421423.png
http://www.speedtest.net/result/690422490.png

woah!!

Now I would like to know how I can make udev take care of the
usb_modeswitch and loading usbserial after a reboot?
Olaf, maybe you can kindly post a udev rule for this? Or how is it done
correctly? I guess modifying usb_modeswitch.conf is the wrong way, or?

thanks, Gün.

Dear all,


as we speak the final files for testing IPCop on x86 machines are making
their way to SourceForge. Which, by the way, will take 2-3 hours due to
my slow connection speed.
Many minor and some larger things were changed, fixed, etc ...

With this beta version you will find many things working and some not
working.
The largest obstacle at the moment probably being IPsec Roadwarrior.

Note that this very likely will not be the latest beta version. I expect
at least 2 or 3 more betas before we go into Release Candidate mode.


Happy testing ...

Olaf


PS: the 1.9.10 -> 1.9.11 update is 15.7 MiB large, if you are on a slow
internet link the GUI can timeout when loading the update. Also expect
to see a 'white screen' when updating, due to some timeout of the IPCop
web page.
Both points will be addressed as soon as possible, so next updates
should go smoother for all.

PPS: updating still beats seeing a 'blue screen' though :-)


===================================


IPCop 1.9.11 is released

v1.9.11 is a BETA version, *DO NOT* use in a productive environment.

Some things will work, for example cleaning your harddisk on installation.
Some things may work.
Some things will not work.

There may be updates to later versions, but it is possible that a full
installation is required to use newer versions.


If you want to help, you can do so by testing and reporting any issues
you should find. Reports should go to the ipcop-devel mailing list.
Make sure that reports are verbose! also specify the exact version you
have been testing, either 1.9.11 or SVN version number if you are building
IPCop by yourself.
A simple "xyz does not work" will get you nowhere! and is more than likely
to be ignored.


For those familiar with earlier IPCop versions, IPCop v2 is different.

Noteworthy:
- you need to reboot to use the new kernel after upgrading to 1.9.11.
- the GUI uses 8443 instead of 445
- SSH uses 8022 instead of 222
- access to IPCop and to the internet from internal networks (aka
Green, Blue, Orange) is very much different. Spend some time with the
various options you will find under "Firewall Settings" and the online
admin manual.
- translations are not yet complete
- (online) manual is not yet complete but large sections are available
and worth reading.


v1.9.11 is a BETA version, *DO NOT* use in a productive environment.


http://sourceforge.net/projects/ipcop/files/IPCop%20Test%20Versions/IPCop%201.9.11

Updates
f8bc59e5bb73f5ef229a644369c8c39e  ipcop-1.9.11-update.i486.tgz.gpg

Installation
962de1b395293860f5f29d7c0072ccd7  ipcop-1.9.11-install-avmdrv.i486.tgz
809299c8b27a026a40339d5047a1ade4  ipcop-1.9.11-install-cd.i486.iso
61ee4333ae723e7ae9ee819080f35134  ipcop-1.9.11-install-netboot.i486.tgz
a14b38c1cdc0f7a42a1cbf2e44422c8a  ipcop-1.9.11-install-usb-fdd.i486.img.gz
fd2cbd2f02b00af96d68030f9c47a462  ipcop-1.9.11-install-usb-hdd.i486.img.gz
557b62899cf5ebccb172c981a32506e5  ipcop-1.9.11-install-usb-zip.i486.img.gz

Selon ow...@us...:

...
>
> TODO: combine ipcopbkcfg and ipcopbackup into one backup program?
>

I didn't do that on 1.4 because the 2 programs work with a different logic for
include files.
But yes, that would be a good move because of the reduced number of people who
know and understand that difference.

Gilles

> The 1.9.11 version will probably be an update again, but also have
> installation files.
> Included (among other things) will be latest 2.6.27 kernel and iptables
> 1.4.6.
> I plan to release that by the end of next week.

Make that the end of this week.

Any changes, other then those concerning chpasswd.cgi and language DB,
are best kept until after I've released 1.9.11
There is plenty of things we can try in .12, .13, .14 etc. :-D


Olaf

Feature Requests item #2934582, was opened at 2010-01-18 18:18
Message generated for change (Tracker Item Submitted) made by deipa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=2934582&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Next Release (example)
Status: Open
Priority: 5
Private: No
Submitted By: Andre Fernandes (deipa)
Assigned to: Nobody/Anonymous (nobody)
Summary: BOTs 

Initial Comment:
Functions as dansguardian, anti-virus, be supported? BOTS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=2934582&group_id=40604

Bugs item #2933185, was opened at 2010-01-15 16:35
Message generated for change (Tracker Item Submitted) made by onopoc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2933185&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: 1.4.20
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Onopoc (onopoc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Confirming this issue.

Initial Comment:
Confirming this issue.

Steps to reproduce
-Burn ISO cd from 'ipcop-1.4.20-install-cd.i386.iso' file.
-Boot from CD.
-Press ENTER to boot Ipcop.
-Select ENGLISH
-Select OK
-Select CDROM/USB-KEY option
-Select OK
-Message reads 'Probing SCSI devices...'
-'...Prepare the hardrive on...' Select OK.
-Message reads 'Partitioning disk...'
-Message reads 'Making Log Filesystem...'
-Wait over 15 to 30 minutes. Nothing is happening during this period. That's why it seems like a bug. It looks like  the installer is hanging or frozen. But wait 15 to 30 minutes. Adding a spinning wheel or something that moves on this screen would avoid confusion.
-After the long waiting period the following error screen is display. The screen is red background, blue strip in the middle with white error box in the middle. The messages read as follow
--------------------------------------
Error
Unable to install files.

tar: Bad tar header, skipping
tar: invalid compress data --format violated
tar: Error exit delayed from previous errors

OK [button]
--------------------------------------

Press OK. The computer will reboot. Reinstalling again gives the same result.

Tested with
-Laptop Toshiba M3
-CD/DVD rom
-HD 80GB formatted using Linux EXT 3 format
-Previous operating system already installed was Ubuntu Desktop 8.0.2. And it was working fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2933185&group_id=40604

Eric,
Eric Oberlander schrieb:
>> ok, fine; I've just build r4115; what if I now install this update on
>> commandline which is labeled .11? Does this still keep the possibility
>> to install any later .11 update, f.e. the one provided by you soon?
> 
> Yes, update 1.9.11 will install on version 1.9.10 or 1.9.11, which
> allows you to do multiple updates, if you are testing.
great - did that and now I have 1.9.11-r4115.
I see that Olaf's workaround works so far; it throws a debug message
into the logs about creating the ppp device, and I get no further
missing ppp messages in the logs; also after reboot the ttyHSx (0-3) are
directly available, and the hso driver is loaded, so usb_modeswitch
seems to work too now. However when it comes to connecting I see that
the card doesnt like the dial command; ATD*99# as well as ATD*99***1#
give ERROR back (I've tried to send these commands also with kermit
which showed this error too, and I tried all ttyHSx devices with sme
result). I uses comgt to enter the PIN, and to verify that the card had
registered to the right network, and that the right APN was detected.
Just to make sure that the card works at all with Linux I then tried to
connect with an OpenSuSE 11.2 Gnome liveCD, and that worked fine - same
OS but KDE4 didnt work (but since it didnt even try to connect I guess
there's again something broken ...).

Any hints what else I could try are welcome!

thanks,  Gün.

> ok, fine; I've just build r4115; what if I now install this update on
> commandline which is labeled .11? Does this still keep the possibility
> to install any later .11 update, f.e. the one provided by you soon?
>
> thanks, Gün.

Yes, update 1.9.11 will install on version 1.9.10 or 1.9.11, which
allows you to do multiple updates, if you are testing.

Eric

Hi Olaf,
Olaf Westrik schrieb:
>> thanks! That worked; now on 1.9.10 but still cant select ttyHSx from the
>> dialup page - do we meanwhile have a list where I can add the ttyHSx
>> interfaces? I found only the check for valid tty in pppsetup.cgi, and
>> this doesnt promise that ttyHSx would work ...
>
> There are some modifications in pppsetup.cgi for that, all already
> queued up for 1.9.11.
ok, fine; I've just build r4115; what if I now install this update on 
commandline which is labeled .11? Does this still keep the possibility 
to install any later .11 update, f.e. the one provided by you soon?

thanks, Gün.

I have 8.4 script ready (no error on tests).

One change need consideration.
Following LFS-dev, hostname will be now only compiled on toolchain stage.
One reason is that coreutils configure test for hostname (I didn't look at
what happen is hostname is not available during configure), so having
hostname available during base compilation is a plus.
The major gain is that there is no more two hostname compiled during final
stage (one from coreutils to pass perl tests, one that will be used finally
from net-tools).

The drawback of this change is that a new toolchain package is available as
previous did not include hostname. I would try again to add toolchain
cross-compilation before commiting that.

Gilles