ipcop-devel Mailing List for IPCop Firewall

Bugs item #1804464, was opened at 2007-09-28 18:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1804464&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: User Interface
Group: 1.4.15
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pete Boyd (thegoldenear)
Assigned to: Nobody/Anonymous (nobody)
Summary: web interface wording errors regarding updates

Initial Comment:
The information in the web interface about updates says "Your update file is 70d 12h 43m 48s days old. We recommend you update it on the System>Updates page."

It has errors in these parts:
- "70d 12h 43m 48s days"
- "System>Updates"

I recommend it instead says this:
"Your update file is 70 days 12 hours 43 minutes 48 seconds old. We recommend you update it on the SYSTEM -> UPDATES page."

or this:
"Your update file is 70d 12h 43m 48s old. We recommend you update it on the SYSTEM -> UPDATES page."

Pete Boyd


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

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

Bugs item #1802717, was opened at 2007-09-26 08:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1802717&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bill K (drotta)
Assigned to: Nobody/Anonymous (nobody)
Summary:  Kernel Logging Stopping abruptly 1.4.16 ipcop-Bugs-1801396 

Initial Comment:
Thanks for the Quick Repsonse that was super.

Now the conundrum grows.

I have looked for  'Allocation Failed' /var/log/messages and did not find any.

ps -ax showed the syslog was running pid 81.  Greping the log file for syslog showed that on the 23 and the 29 which it today, that it was restarted but no error message

The webui on IPCOP still shows kernel logging in the stopped or not running.  I still have browsing working so that is different that what I had seen earlier. 

Did not add any memory to the box. The swapfile which is currently sized at 32meg has not had any use when I checked vmstat.

Current memory allocation is sitting at 97 percent which is about 13% higher after doing a restartsyslog.


The only difference in this location is that I have the IPSEC VPN running in combination with Openvpn and zerina. With Ipsec I am running full logging because I had a net-net reconnection fail on restart of this box and I had to restart IPCOP at the remote end to get the connection to resume. It is hot and active now so I cannot bring down the network at this time to turn back logging to normal.

Will kick the box tonight.

Could this maybe a just a webui Issue. Since the server is resported as red.  

Thanks I really apprecate the great product.


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

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

Bugs item #1801396, was opened at 2007-09-24 12:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1801396&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bill K (drotta)
Assigned to: Nobody/Anonymous (nobody)
Summary: Kernel Logging Stopping abruptly 1.4.16

Initial Comment:
Hello,

Have noticed on several occasions that the Kernel Logging stops abruptly. Then we can no longer browse the web.   

I have checked available memory and see around 512 or more Ram is in the machine and Ram usage is around 87%.

I have not explored further in the logs because it was 19days since the last reboot and I am not sure when the Kernel loggin server quit working.

I have copfilter and zerina Loaded.  I use only the havp, privoxy and the clam 91.2. I do not use the rest of the components of that software package. Snort is running also. 

Snort is run on the Red and Green interfaces but not the orange since it is not in use at this time. The rest of the services are pretty normal, dhcp, time, webui, ssh when needed, etc.

Usually stopping havp and privoxy and then in services clear the cache and then repair chache does the trick and gets browsing to work. To get the Kernel server to go green, i cheat and just do a shutdown from the webui.

Great Product.

Thahks.

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

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

Bugs item #1797096, was opened at 2007-09-18 14:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1797096&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: VPN
Group: 1.4.15
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dermot (dermots)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with vpn-watch script

Initial Comment:
I have a net to net VPN set up from my IPCOP to another IPCOP in another country.  My side has static DNS, the remote side has dynamic DNS so we have created a DDNS name for their side.

The VPN can activate and operate successfully but when their IP address changes the VPN goes down and does not get reconnected.  The remote side correctly notifies the DDNS server of the change of IP address.

While debugging this problem I noticed an error in the vpn-watch script that runs locally here trying to detect a change in IP address at the peer.  This is not the complete cause of my problem because it still does not reconnect without someone at the remote side forcing a restart, but it is an error that must be fixed.

The vpn-watch script uses the command /usr/bin/host to lookup the IP address for the configured FQDN of the peer.  I think the output from /usr/bin/host must have changed some time, because the remainder of the function to get the IP address fails and the script tries 3 times then terminates.

The output from /usr/bin/host is like this:

  peer.dyndns.org has address 12.34.56.78
  peer.dyndns.org mail is handled by 10 mail.fred.net.

I think the reporting of MX record results must be a recent change to /usr/bin/host (in fact I think it is a bug in /usr/bin/host since the default operation is meant to return only A records, not MX).  The check for a valid IP address fails because the second line is present.

The following change in get_ip() fixes the script:

OLD:
RESULT=$(/usr/bin/host "$1" 2>/dev/null| awk '{ print $4 }')

NEW:
RESULT=$(/usr/bin/host -t A "$1" 2>/dev/null| awk '{ print $4 }')

With this change my side sees the IP address change and restarts VPN services, but the VPN still does not come back up until someone at the other side manually selects restart of the VPN entry.  I will keep on debugging but if anyone has any ideas I would be pleased to hear them.  The debug options for VPN generate a lot of output, but it is not easy to follow...

Dermot


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

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

I think threatstop.com does this.
It uses IPTables to block based on a distributed list.  Is this what you
meant?
http://www.threatstop.com/component/option,com_easyfaq/task,cat/catid,28/Ite
mid,35/

-- 
Dave Taylor
 
> 
> To this day now, I still do it by hand.
> 
> Seems like common things like BOGON lists should be automatic. I
> digress though...
> 
> The Proxy URL addon filter thing kicks ass though. For cutting through
> ads and junk. Dunno who made that mod, but I wish they'd port the
> iptables cidr banning ideas I had.
> Hell, Why ain't a cidr binary on ipcop?  to reverse threats...
> e.g. IP cidr -a xxx.xxx.xxx.xxx && ban xxx.xxx.xxx/24 && ipbansync
> 
> Okay okay,
> enough off topic... ;o)  I still LOVE YA.  hope ya love me still.
> I wouldn't be here if it wasn't for you.
> ~phil
> [/OFF IPCOP TOPIC]
> 

Hello Everyone,

I remember Phil Barnett.  o;)  Awesome!!
aye Phil, it's Phil!!  ;o)

Sunday, September 16, 2007, 6:45:21 AM, you wrote:

> ipc...@li... 16 Sep 2007 at 0:09, Phil Barnett wrote:

>> On Saturday 15 September 2007, David W Studeman wrote:
>> > Then reinstall it from scratch or simply change the driver module
>> > in /var/ipcop/ethernet/settings for the green driver. You are just trying
>> > to change the green driver aren't you?
>> 
>> There are probably many reasons that I might want this without a reinstall, 
>> such as:
>> 
>> Someone calls me with a dead IPCop. There is no backup. The hard drive is 
>> still good and there is a good deal of customization done. It'd like to pop 
>> it into new hardware, run setup and tell it to forget it's interfaces and 
>> start over. 10 minutes later, it's up and running.
>> 
>> I've done reinstalls many times over the last 6 or 7 years when all that 
>> really needed done was an interface refresh. It's a waste of time that should 
>> be handled inside the product.

> I just looked inside the latest IPcop .iso and /var/ipcop/ethernet has two
> files in it, aliases and settings.  Both are 0-byte files.  I suspect you could
> rename both existing files on the HD from the dead box, create two new 0-byte
> files, and just run setup from there.  However, I would experiment with this on
> a box of my own before trying it on a client box.  It could be that the
> original 'setup' is run with special options during the first boot.

> You might need to erase/rename all the files in /var/ipcop/red as well.

that's really cool you all are discussing this. I just went through
this recently.

I just went searching through directories, and searching the web for
hints on where the hell the settings are.

With Old 3COM hardware blowing out (END OF LIFE MAN...). I slapped in some
realtek 8139 fast. Everything works, except on boot it still looks for
that damn 3c509 then doesn't find it and instead try's to insmod the
TULIP card (tulip don't exist on my box), so then I pop a cold/reboot
straight from setup again and then I get it to come up with the
realtek 8139 card.

Box been running since smoothwall days. It's a small price
to pay to reboot a couple times to keep it running currently, and I
think the added card detection/insmod glitch is an added bonus to
LOCAL security.  ;o)

I ain't sure if it's the etherlink III card now or just a bad insmod
3c509. (I know neither of those have nothing to do with realtek,
although there is another name that is wrong, and that's when I Kill
power off and reboot) I would love to re-detect all the hardware, but I can
understand WHY it behaves like this to keep the LOCAL network up.

All the crap is in the logs but I don't bother to post it here.  I
like to just wipe the logs out. I been experimenting with that.

My intuition says, it's that it's detecting the WRONG card early on,
and then it tries to install the TULIP module in the wrong card
assignment. The original hardware if I recall was etherlink III =
Green 3c509 = Red 3c509 = Orange and 3c509 = Blue , and ORIGINALLY I
had to install them one at a time and change jumpers for the IRQ's on
the 3C509's...

I have since yanked ORANGE and BLUE out.  Over time.. First I stopped
running wireless, then I stopped running a BBS.

If 1.5 gave options to fix the local card, and gave a remote / local
CONFIRM MY ASS WARNING that the network could go all the way down
completely, I'd think that'd be useful. But then I ain't active on
IPCOP years now.  Buuuuurrrrrrpppp I think.

[OFF IPCOP TOPIC]
The IP-Banning mods are not up to snuff still . . .  if you ask me.  I broke
that crap one day...  o;)

To this day now, I still do it by hand.

Seems like common things like BOGON lists should be automatic. I
digress though...

The Proxy URL addon filter thing kicks ass though. For cutting through
ads and junk. Dunno who made that mod, but I wish they'd port the
iptables cidr banning ideas I had.
Hell, Why ain't a cidr binary on ipcop?  to reverse threats...
e.g. IP cidr -a xxx.xxx.xxx.xxx && ban xxx.xxx.xxx/24 && ipbansync

Okay okay,
enough off topic... ;o)  I still LOVE YA.  hope ya love me still.
I wouldn't be here if it wasn't for you.
~phil
[/OFF IPCOP TOPIC]



> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel


-- 
Best regards,
 fsckdsl                            mailto:fs...@gm...

----- Original Message ----- 
From: "Phil Barnett" <ph...@ph...>
To: <ipc...@li...>
Sent: Sunday, September 16, 2007 6:09 AM
Subject: Re: [IPCop-devel] Pre hardware detection state.


> On Saturday 15 September 2007, David W Studeman wrote:
> > Then reinstall it from scratch or simply change the driver module
> > in /var/ipcop/ethernet/settings for the green driver. You are just
trying
> > to change the green driver aren't you?
>
> There are probably many reasons that I might want this without a
reinstall,
> such as:
>
> Someone calls me with a dead IPCop. There is no backup. The hard drive is
> still good and there is a good deal of customization done. It'd like to
pop
> it into new hardware, run setup and tell it to forget it's interfaces and
> start over. 10 minutes later, it's up and running.
>
Change green card settings manually and other will be set by setup.
That will work with 0 risk.
I have no time now to change setup to accept changing the green card.
If a patch is not too intrusive, I may accept it in 1.4 but this is not
assured.

> I've done reinstalls many times over the last 6 or 7 years when all that
> really needed done was an interface refresh. It's a waste of time that
should
> be handled inside the product.
>
If the disk is IDE, that's easy. Usb detection is just an alias.

Gilles

ipc...@li... 16 Sep 2007 at 0:09, Phil Barnett wrote:

> On Saturday 15 September 2007, David W Studeman wrote:
> > Then reinstall it from scratch or simply change the driver module
> > in /var/ipcop/ethernet/settings for the green driver. You are just trying
> > to change the green driver aren't you?
> 
> There are probably many reasons that I might want this without a reinstall, 
> such as:
> 
> Someone calls me with a dead IPCop. There is no backup. The hard drive is 
> still good and there is a good deal of customization done. It'd like to pop 
> it into new hardware, run setup and tell it to forget it's interfaces and 
> start over. 10 minutes later, it's up and running.
> 
> I've done reinstalls many times over the last 6 or 7 years when all that 
> really needed done was an interface refresh. It's a waste of time that should 
> be handled inside the product.

I just looked inside the latest IPcop .iso and /var/ipcop/ethernet has two 
files in it, aliases and settings.  Both are 0-byte files.  I suspect you could 
rename both existing files on the HD from the dead box, create two new 0-byte 
files, and just run setup from there.  However, I would experiment with this on 
a box of my own before trying it on a client box.  It could be that the 
original 'setup' is run with special options during the first boot.

You might need to erase/rename all the files in /var/ipcop/red as well.

Bugs item #1795670, was opened at 2007-09-15 23:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1795670&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: Security (Patches etc)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: choprzrul (choprzrul)
Assigned to: Nobody/Anonymous (nobody)
Summary: login retention

Initial Comment:
I built another IpCop box this afternoon to replace an aging version currently in production.  I used the same naming convention on the new machine as what is found on the old machine.  I was logged in to the old machine via web browser so that I could switch my kvm back and forth to verify settings.  When finished I unplugged the network cable from the old machine and plugged it in to the new machine.  I then hit refresh on the web page so that I could log into the new box and continue working on it.  To my suprise, I didn't have to log in to the new box to access its configuration pages.  This seems like a potential security vulnerability albeit a small one.  I just thought you might like to know.

Kevin

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

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

On Saturday 15 September 2007, David W Studeman wrote:
> Then reinstall it from scratch or simply change the driver module
> in /var/ipcop/ethernet/settings for the green driver. You are just trying
> to change the green driver aren't you?

There are probably many reasons that I might want this without a reinstall, 
such as:

Someone calls me with a dead IPCop. There is no backup. The hard drive is 
still good and there is a good deal of customization done. It'd like to pop 
it into new hardware, run setup and tell it to forget it's interfaces and 
start over. 10 minutes later, it's up and running.

I've done reinstalls many times over the last 6 or 7 years when all that 
really needed done was an interface refresh. It's a waste of time that should 
be handled inside the product.

-- 
Phil Barnett
AI4OF
SKCC #600

> > I want to make IPCop forget everything it has learned about my network
> > interfaces so I can start the complete detection cycle over using setup.
> 
> Then reinstall it from scratch or simply change the driver module 
> in /var/ipcop/ethernet/settings for the green driver. You are just trying to 
> change the green driver aren't you?

I believe Phil is trying to make changing GREEN faster and easier for 
the user that reinstall.  I believe this is a good course of action.

BUT...

Is it right 1.4?  Should this be one of goals for version 2.0?

jackb

On Saturday 15 September 2007 12:23:38 am Phil Barnett wrote:
> On Saturday 15 September 2007, Gilles Espinasse wrote:
> > I don't know what you attempt to do.
> >
> > Hardware detection code is in the installer.
> > when the installer run, every access to the hard disk is made from a
> > chroot, so I don't think it is possible to run the installer when booting
> > from the hard disk.
>
> I want to make IPCop forget everything it has learned about my network
> interfaces so I can start the complete detection cycle over using setup.

Then reinstall it from scratch or simply change the driver module 
in /var/ipcop/ethernet/settings for the green driver. You are just trying to 
change the green driver aren't you?

Dave

On Saturday 15 September 2007, Gilles Espinasse wrote:

> I don't know what you attempt to do.
>
> Hardware detection code is in the installer.
> when the installer run, every access to the hard disk is made from a
> chroot, so I don't think it is possible to run the installer when booting
> from the hard disk.

I want to make IPCop forget everything it has learned about my network 
interfaces so I can start the complete detection cycle over using setup.

-- 
Phil Barnett
AI4OF
SKCC #600

----- Original Message ----- 
From: "Phil Barnett" <ph...@ph...>
To: <ipc...@li...>
Sent: Saturday, September 15, 2007 6:07 AM
Subject: Re: [IPCop-devel] Pre hardware detection state.


> On Friday 14 September 2007, Gilles Espinasse wrote:
> > - green netcard
> > in /var/ipcop/ethernet/settings
>
> So, if this file were deleted, would the network interface process start
over
> clean, or do I need to delete it and then touch it?
>
touch the file and make it owned by 'nobody' user.

I don't know what you attempt to do.

Hardware detection code is in the installer.
when the installer run, every access to the hard disk is made from a chroot,
so I don't think it is possible to run the installer when booting from the
hard disk.

Gilles

On Friday 14 September 2007, Gilles Espinasse wrote:
> - green netcard
> in /var/ipcop/ethernet/settings

So, if this file were deleted, would the network interface process start over 
clean, or do I need to delete it and then touch it?

-- 
Phil Barnett
AI4OF
SKCC #600

----- Original Message ----- 
From: "Phil Barnett" <ph...@ph...>
To: <IPC...@li...>
Sent: Friday, September 14, 2007 2:52 PM
Subject: [IPCop-devel] Pre hardware detection state.


>
> Does anyone here know what files need to be deleted and what files need to
be
> cleaned to return an IPCop installation to the state it was in before it
> detected it's interfaces?
>
> I would like to provide a patch to setup to make this change, but I'm not
sure
> what gets changed as the detection process moves forward.
>
Hardware detection detect three parts during install:
-usb
alias is written in /etc/modules.conf

- green netcard
in /var/ipcop/ethernet/settings

- hard disk controller if scsi or raid
depending if IDE or SCSI|RAID, a different grub.conf is installed
On SCSI|RAID, the driver detected is used to build an initrd
You could look at updates/1.4.13/setup ho to rebuild the initrd

Gilles

Does anyone here know what files need to be deleted and what files need to be 
cleaned to return an IPCop installation to the state it was in before it 
detected it's interfaces?

I would like to provide a patch to setup to make this change, but I'm not sure 
what gets changed as the detection process moves forward.

-- 
Phil Barnett
AI4OF
SKCC #600

Bugs item #1792662, was opened at 2007-09-11 14:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1792662&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bill K (drotta)
Assigned to: Nobody/Anonymous (nobody)
Summary: DHCP Failing to Renew leases on Connected Computers

Initial Comment:
I have run into two cases where the DHCP is not renewing leases of computers that are actively running on the network.

One case involved a New IPCOP 1.4.16 installation and two computers. The affected computer was an HP laptop. I was able to connect to the network by using a fixed ip address so the NIC on the the Laptop was working fine.  

The compters reported error communicating with the DHCP server and a lease was notable to be obtained when doing ipconfig /release then the renew function.

It was not until i restarted IPCOP was I able to get DHCP to function accordingly.  The Laptop has broad Com Nic and the Desktop had Intel. THe desktop never had any problems with renewing the ip address.

The Firewall is a Pentium 4. 2.8gz, Gigabyte MB with Intell 100 mbs nics on Red, and Green. 1 gig ram.  Addon include Zerina and Copfilter.


The second Incident involved 8 pcs on a 20 pc network. The remainder are fixed IP addresses. In that case each PC was able to resume normal connectivity once I provided them with a fixed IP addressing information. 


This network had been in place since OCT 2006.
I kicked the box and upon reboot and put each work station back to DHCP and they were fine. This latter network involved HP PCs and Laptops with the Nics in the firewall being RTL 8139 based NICS from AOPEN.  Same firewall config just 640mb ram.


Common thing was that each box was at 1.4.15 and each was upgraded to 1.4.16.  All were HP computers and parts but differing nics from Broadcom, Intel to RTL. All PCs were running XP Pro.

Thanks

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

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

Bugs item #1790528, was opened at 2007-09-07 22:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1790528&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: User Interface
Group: 1.4.16
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason Schmidt (zannalov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Slow/delay DHCP screen display

Initial Comment:
Our internet connection was recently switched to a new IP range using a new DSL modem.  In changing IPCop to the new settings, I noticed that the DHCP screen ( "Services" -> "DHCP Server" , AKA dhcp.cgi ) was taking a very long time to load at the point of displaying the fixed leases.  After tracing the source code, I found the problem in /var/ipcop/general-functions.pl in the General::IpInSubnet command.  When the start and mask are passed as an empty string (I have yet to look into why this is happening), the Socket::inet_aton call delays by several seconds, which when run multiply, adds up to quite a delay on the screen.  I've written a simple solution for the time being, which checks that the input contains a non-empty value, and which also skips the lookup if the value passed is already in a valid IP address format.  It's not perfect, but I wanted to point this out and to provide a possible fix to work from.

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

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

Bugs item #1786738, was opened at 2007-09-02 21:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1786738&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: User Interface
Group: 1.4.16
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: mailminator (mailminator)
Assigned to: Nobody/Anonymous (nobody)
Summary: Settings won't set with opera

Initial Comment:
Version
9.23
Build
660
Platform
Linux
System
i686, 2.6.20-16-generic
Qt library
3.3.7

Using the above verson of opera some settings are not set. Examples of this is:
system - updates --Refresh updates button does not work, it seems to work(refresh site) but doesnt actually fetch a new updates file. "system - home" still ask me to check for updates.

Example2:
Services - traffic shaping --add services does not work. 

Everything works with firefox though so im not quite sure if this bug belongs to opera or ipcop. But most stuff works with opera and I have not experienced this on other sites so I post this to let you know just in case.

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

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