ipcop-devel Mailing List for IPCop Firewall

Olaf wrote:
 
> The use of TLS will have to wait until after 2.1.0/2.1.1.
> Achim and myself are currently looking into the update issue, which
> looks like the GUI showing an error when in fact everything is updated OK.
> 
> Expect -rc2 next week and then 2.1.0/2.1.1 some time after that.
> 
> 
> Olaf

On the one update test I tried thus far, I had to run restarthttpd to get 
the updates web gui page back. It went fine otherwise. 

I'm not sure if this was just a fluke since the machine I tested on has been 
giving me other problems as of late such as ethernet interfaces crashing at 
random ie not the same one each time or hard lockups while streaming over a 
ralink usb wlan using the proper firmware and the WLAN AP. This was my 
original Raq4 I had in service since June 2007. I see no bulging caps at 
first glance which the Raq3 and 4's have been known to do. Sound like 
hardware to you?

-- 
Dave Studeman
http://www.raqcop.com 

>> ***
>> 2.1.1-rc1 is for testing purposes and cannot be updated to 2.1.1.
>> ***
>
> 2 issues remain to be fixed:
> - proper use of TLS encryption in sendEmail
> - update to 2.1.0/2.1.1 fails in some situations
>
> After these are fixed it is time for rc-2


The use of TLS will have to wait until after 2.1.0/2.1.1.
Achim and myself are currently looking into the update issue, which 
looks like the GUI showing an error when in fact everything is updated OK.

Expect -rc2 next week and then 2.1.0/2.1.1 some time after that.


Olaf

Dear Christian,

thank you very much for correcting my point of view, I studied the trace
again and I agree with you.

The DSLAM didnt send the requested replies.

But otherwise if DSLAM sent a request, IPCOP answered with a reply
immediatly.

I contacted my ISP with these facts.

Thank you for your help.

Best regards

Michael

Am 18.01.2014 01:40, schrieb Michael Kreitner:
> I filtered for ppp.lcp pakets and I found a strange behaviour:
>
> IPCOP seems to ignore LCP ack's from IPS/DSLAM when the upload bandwith
> is under load.
>
>
> I added the trace, some background information for better reading :
> Cisco_b9:de:01 = DSLAM from ISP/Inode
> Fabiatec_04:e7:70 = WAN interface from my IPCOP
>
Hi,
my reading of the traces is as follows:
The last answered ping request from IPcop is entry 14
The requests in entries 20, 25 and 30 do not have an "Echo Reply"
as a consequence the connection is requested to be terminated in entry 35.

14    49.139909000    Fabiatec_04:e7:70    Cisco_b9:de:01    PPP LCP    
60    Echo Request
15    49.161099000    Cisco_b9:de:01    Fabiatec_04:e7:70    PPP LCP    
60    Echo Reply

20    69.150306000    Fabiatec_04:e7:70    Cisco_b9:de:01    PPP LCP    
60    Echo Request

25    89.160700000    Fabiatec_04:e7:70    Cisco_b9:de:01    PPP LCP    
60    Echo Request

30    109.171085000    Fabiatec_04:e7:70    Cisco_b9:de:01    PPP LCP    
60    Echo Request

35    129.195266000    Fabiatec_04:e7:70    Cisco_b9:de:01    PPP LCP    
60    Termination Request


>
> 35 129.195266000 Fabiatec_04:e7:70 Cisco_b9:de:01 PPP LCP 60 Termination
> Request ---> I dont know why IPCOP decides here to terminate the
> connection!!!!
>
> 36 129.277674000 Cisco_b9:de:01 Fabiatec_04:e7:70 PPP LCP 60 Termination Ack
>
> Trace:
>
> https://www.dropbox.com/s/36csf4grte84odk/ppp.lcp.only.pcapng
>
>
> I am able to reproduce this fault at any time.
>
>
> With Google I found a lot of peoples with the same problem, but I didnt
> found a solution.
>
> Maybe you have an idea?
>
> Thank you.
>
> Best regards,
>
> Michael
>
>
>

Dear IP-COP Developers!

Actually I am using IPCOP 2.0.6 with a DLINK DSL Modem DSL-320 B in
brigde mode on a XDSL-line with the PPPOE-plugin.

Everytime when I am filling my uploadbandwith (max. 100kbyte/s) with
more than 80% of the possible traffic, the IPCOP will starts with
reconnects randomly:



19:35:14 red Dialling XDSL.INODE.AT.
19:35:14 red Starting RED device wan-1 type PPPOE.
19:35:13 connectioncheck Will connect again
19:35:12 red rc.updatered (pid 21629) end
19:35:07 red rc.updatered (pid 21629) parameters: ppp down
19:35:06 pppd[19593] Exit.
19:35:06 pppd[19593] Script /etc/ppp/ip-down finished (pid 21626),
status = 0x0
19:35:06 red rc.connectioncheck reconnect started
19:35:04 pppd[19593] script /etc/ppp/ip-down, pid 21626
19:35:04 pppd[19593] Waiting for 1 child processes...
19:35:03 pppd[19593] Connection terminated.
19:35:03 pppd[19593] rcvd [LCP TermAck id=0x2]
19:35:03 pppd[19593] sent [LCP TermReq id=0x2 "Peer not responding"]
---> I dont know why IPCOP decides here to terminate the connection!!!!
19:35:03 pppd[19593] Script /etc/ppp/ip-down started (pid 21626)
19:35:03 pppd[19593] Sent 512566670 bytes, received 519731584 bytes.
19:35:03 pppd[19593] Connect time 160.5 minutes.
19:35:03 pppd[19593] Serial link appears to be disconnected.
19:35:03 pppd[19593] No response to 3 echo-requests
16:54:46 red rc.updatered (pid 19600) end
16:54:43 connectioncheck Connected
16:54:39 red rc.updatered (pid 19600) parameters: ppp up
16:54:39 pppd[19593] Script /etc/ppp/ip-up finished (pid 19594), status
= 0x0

I had this problem with IPCOP 1.4 and a Fritzbox 7270 on the same XDSL
line too.

Meanwhile I replaced everything:
IPCOP Hardware, cables, modem, IPCOP version
But I have still these stupid reconnects.

If I checked the modem XDSL line, I didnt saw an interuption on dsl-level.

My ISP told me, that the reconnects where initiated by my IPCOP pppd.

Today I started with tracing the ppp traffic between DSLAM and WAN-Port
of IPCOP.
I installed between WAN port of IPCOP and DLINK DSL modem an hub from
Netgear.
Additionally I plugged my laptop into this hub too.

Which this modification of my setup I was able to sniffing the traffic
between modem and IPCOP.

I filtered for ppp.lcp pakets and I found a strange behaviour:

IPCOP seems to ignore LCP ack's from IPS/DSLAM when the upload bandwith
is under load.


I added the trace, some background information for better reading :
Cisco_b9:de:01 = DSLAM from ISP/Inode
Fabiatec_04:e7:70 = WAN interface from my IPCOP



35 129.195266000 Fabiatec_04:e7:70 Cisco_b9:de:01 PPP LCP 60 Termination
Request ---> I dont know why IPCOP decides here to terminate the
connection!!!!

36 129.277674000 Cisco_b9:de:01 Fabiatec_04:e7:70 PPP LCP 60 Termination Ack

Trace:

https://www.dropbox.com/s/36csf4grte84odk/ppp.lcp.only.pcapng


I am able to reproduce this fault at any time.


With Google I found a lot of peoples with the same problem, but I didnt
found a solution.

Maybe you have an idea?

Thank you.

Best regards,

Michael


-- 
Michael Kreitner

Hard drive install.

I experienced the same issue with rc1 from the 9 Dec build.



> I'm not seeing this behavior. All my test installs are flash based. Are you
> using a hard drive install or flash install?
>
>

Olaf wrote:


> ISDN is not very good for internet, but for 'normal' voice it is
> excellent. 2 (working!) simultaneous calls, without having to worry
> about bandwidth like with VoIP.

Of course if one has a PRI which is a T1 and dedicates it to VOIP it's as 
good as it gets since you are using a carrier grade connection. In the US, 
ISDN never replaced POTS like it should have and people mistakenly compare 
VOIP to POTS whereas it should be compared to ISDN voice especially if you 
use g.711 as a minimum quality codec. VOIP using g.711 would not quite fit 
in a 64K B channel using data as there is a bit of overhead bringing it to 
80kbs. My Bandwidth meter on my Raq shows 10 up and down steadily in KBs 
during conversations. You could only fit one g.711 or g.722 conversation via 
VOIP using both B channels only but nothing else could use either B channel. 
Yeah, ISDN voice is great but for data it's puny with a BRI and only two B 
channels. 

Here it is really ISDN to the CO but then converted via a narrow band SLIC 
to analog and then that is carried via twisted copper to and into the 
premises. I use what is called a dry loop with no POTS on it and only ADSL. 
My connection can rival carrier grade most of the time but sometimes the 
latency and jitter go up momentarily. 

I've been using a Snom M9R since October and while not perfect with every 
feature I want, namely that dial plan concatenation does not yet work and it 
would be nice to have the RSS prompt not on the screen if none is set up. 
The actual call quality has been very nice and I love the form factor. The 
original M9 got bad reviews, the firmware has improved greatly since then 
and the new R model has more memory and will support a repeater. There 
aren't too many options when it comes to DECT IP phones that support more 
than six accounts and support g.722. 

Like everything else, when I got into VOIP I went a bit (ok, a lot) above 
and beyond what's needed (it turned into yet another hobby) and now I wound 
up with several carriers and many DIDs. Not what the average household 
needs. With a single carrier and unlimited channels, a household could use 
all handsets simultaneously one ONE phone number holding separate 
conversations on each handset. Probably why residential plans are different 
than business plans. If they only had this when I was a young man in a 
household with five sisters, I could have gotten more phone calls.
-- 
Dave Studeman
http://www.raqcop.com 

Jon M wrote:

> After installing svn 7213 the Logging server is STOPPED in the UI.  And it
> stays stopped in the UI until a reboot.  *Logs* > *Firewall Logs* has data
> for day 1 (date of install).  But is blank for day 2 and day 3 after the
> install.  *Logs* > *System Logs* > all *Sections* have data for day 1 and
> are blank for day 2 and day 3.

I'm not seeing this behavior. All my test installs are flash based. Are you 
using a hard drive install or flash install?
-- 
Dave Studeman
http://www.raqcop.com 

After installing svn 7213 the Logging server is STOPPED in the UI.  And it
stays stopped in the UI until a reboot.  *Logs* > *Firewall Logs* has data
for day 1 (date of install).  But is blank for day 2 and day 3 after the
install.  *Logs* > *System Logs* > all *Sections* have data for day 1 and
are blank for day 2 and day 3.

Rebooting IPCop seems to get the logging server running and most
*Sections*in day 2 and day 3 have data in the UI.

Let me know if you would like additional details.

Thank you for your efforts!  Best regards,
Jon

On 2014-01-08 14:31, David W Studeman wrote:

>> Annex B, due to the large number of ISDN users
>> http://en.wikipedia.org/wiki/Integrated_Services_Digital_Network#Germany
>
> Oh, Annex B. I used ISDN for years but none of my neighbors did. I only had
> two B channels though so it was not a bandwidth fireball.

ISDN is not very good for internet, but for 'normal' voice it is 
excellent. 2 (working!) simultaneous calls, without having to worry 
about bandwidth like with VoIP.


Olaf

On 1/11/2014 9:39 AM, David W Studeman wrote:
> Olaf <mailinglists@...> writes:
>
>> I've made a small modification in the new rules to work with our udev.
>> Tested to give us by-label, by-path and by-uuid same as we have without
>> RAID.
>>
>> Olaf
>
> Sounds good. I'll try it when I get home from work today.
>

Works great! Thanks!

-- 
Dave Studeman
http://www.raqcop.com

Olaf <mailinglists@...> writes:

> I've made a small modification in the new rules to work with our udev.
> Tested to give us by-label, by-path and by-uuid same as we have without 
> RAID.
> 
> Olaf

Sounds good. I'll try it when I get home from work today.

-- 
Dave Studeman
http://www.raqcop.com

On 2014-01-11 03:32, David W Studeman wrote:

> It would appear that the patch is not enough to make the existing udev work
> with the new mdadm rules as I had hoped it would. It does however at least
> point the disk by id to the proper md arrays this time around.

OK, but since we do not have /dev/disk/by-id on a standard IPCop there 
is no need for it.


> The patch I referenced earlier seems to be geared for>  udev-171-r8.
>
> At this point I honestly don't know exactly what it would take to make udev
> 166 work with mdadm 3.3 udev raid rules as there are many differences in the
> newer udev compared to 166. To be clear, It was the old mdadm udev rules
> that made it work thus far in my tests with the existing udev.

I've made a small modification in the new rules to work with our udev.
Tested to give us by-label, by-path and by-uuid same as we have without 
RAID.


Olaf

Olaf wrote:

> 
> 
>> I just tried an experiment. With no other changes I simply moved the two
>> udev raid rules files that the latest mdadm gives us and in their place I
>> put the old single raid rules file and it worked perfectly. I have my
>> disk by label and the root links to md0 and varlog_comp (since this is
>> flash) links to md1 as it should. So now there are three ways to fix
>> this. Patch the existing udev, update udev or simply substitute the old
>> single rules file in lieu of the two new rules files that come with
>> mdadm.
>>
>> I just tried this successfully on a second machine and it works
>> perfectly.
> 
> Thanks Dave.
> 
> I'll go with the patch.
> 
> Olaf
> 
It would appear that the patch is not enough to make the existing udev work 
with the new mdadm rules as I had hoped it would. It does however at least 
point the disk by id to the proper md arrays this time around.

The patch I referenced earlier seems to be geared for > udev-171-r8.

At this point I honestly don't know exactly what it would take to make udev 
166 work with mdadm 3.3 udev raid rules as there are many differences in the 
newer udev compared to 166. To be clear, It was the old mdadm udev rules 
that made it work thus far in my tests with the existing udev. 
-- 
Dave Studeman
http://www.raqcop.com 

> I just tried an experiment. With no other changes I simply moved the two
> udev raid rules files that the latest mdadm gives us and in their place I
> put the old single raid rules file and it worked perfectly. I have my disk
> by label and the root links to md0 and varlog_comp (since this is flash)
> links to md1 as it should. So now there are three ways to fix this. Patch
> the existing udev, update udev or simply substitute the old single rules
> file in lieu of the two new rules files that come with mdadm.
>
> I just tried this successfully on a second machine and it works perfectly.

Thanks Dave.

I'll go with the patch.

Olaf

David W Studeman wrote:

> Olaf wrote:
> 
> 
>> Using the /dev/disk/by-label/root link is much easier :-)
>> I'd have to look, but IIRC it is also used elsewhere. Verifying
>> available disk space before update comes to mind.
>> 
>> 
>> Olaf
>> 
> 
> OK, I see what's happening. The new mdadm udev rules use devnode which
> does not exist in the version of udev used here. It does exist in newer
> versions of udev. Here is the link to a patch I found which is only needed
> if the older versions of udev are still used:
> 
> http://bugs.funtoo.org/secure/attachment/11384/devnode.patch

I just tried an experiment. With no other changes I simply moved the two 
udev raid rules files that the latest mdadm gives us and in their place I 
put the old single raid rules file and it worked perfectly. I have my disk 
by label and the root links to md0 and varlog_comp (since this is flash) 
links to md1 as it should. So now there are three ways to fix this. Patch 
the existing udev, update udev or simply substitute the old single rules 
file in lieu of the two new rules files that come with mdadm. 

I just tried this successfully on a second machine and it works perfectly. 
-- 
Dave Studeman
http://www.raqcop.com 

Olaf wrote:


> Using the /dev/disk/by-label/root link is much easier :-)
> I'd have to look, but IIRC it is also used elsewhere. Verifying
> available disk space before update comes to mind.
> 
> 
> Olaf
> 

OK, I see what's happening. The new mdadm udev rules use devnode which does 
not exist in the version of udev used here. It does exist in newer versions 
of udev. Here is the link to a patch I found which is only needed if the 
older versions of udev are still used:

http://bugs.funtoo.org/secure/attachment/11384/devnode.patch
-- 
Dave Studeman
http://www.raqcop.com 

On 2013-12-27 22:50, David W Studeman wrote:

>>    IPCop contains both the deprecated prism54 and the newer p54 drivers.
>> The newer driver supports both SoftMac and the older FullMac hardware
>> whereas prism54 only supports the FullMac hardware. When this hardware
>> is used, both versions end up being loaded. I can't think of any reason
>> other than firmware hell to keep the prism54 in the IPCop kernel.
>
> All that is need is changing this: CONFIG_PRISM54=m
> To this: # CONFIG_PRISM54 is not set
> On line 1761 of the existing kernel.config.i486. There is no need to do a
> make menuconfig in this case in the kernel tree.

Fixed in #7195.

> It would appear that the Sparc and Power PC configs also have the conflict.
> The Alpha config does not appear to have the same options.

I'd expect all non-i486 kernel configs to have conflicts, problems, or 
even worse...


Olaf

Olaf wrote:

> On 2014-01-03 15:28, David W Studeman wrote:
> 
>>>> Olaf, did you ever get to test one of the Geos units from Traverse? To
>>>> anyone else reading, the Traverse Geos platform has the solos-pci built
>>>> into the motherboard and can be had in single or dual adsl config but
>>>> not the quad port like the pci mammoth I have to play with. Traverse
>>>> has been better about updated firmware lately for their cards they spun
>>>> off to Rocksolid.
>>>
>>> Yes, worked properly.
>>> Special version of the ADSL firmware is required to deal with the Annex
>>> version we run here in Germany.
>>
>> If I remember correctly you are in Annex M territory?
> 
> Annex B, due to the large number of ISDN users
> http://en.wikipedia.org/wiki/Integrated_Services_Digital_Network#Germany

Oh, Annex B. I used ISDN for years but none of my neighbors did. I only had 
two B channels though so it was not a bandwidth fireball.
 
-- 
Dave Studeman
http://www.raqcop.com 

Olaf wrote:

> On 2014-01-06 11:17, David W Studeman wrote:
>> David W Studeman wrote:
>>
>>
>>>
>>> I'm a bit baffled as to what could have changed to cause any of these
>>> things?
>>
>> Update. I see that udev creates the links but the one thing that changed
>> recently is the mdadm upgrade and the udev rules created by it. Mdadm now
>> has two rules sets rather than one from previous versions and there are
>> quite a few differences. This was a major mdadm change from the previous
>> version according to the documentation.
> 
> Yes, the display in status.cgi is related but differently. Fixed in #7203.

Yes, that fixed the display. Thanks!

>> At this point, not having the links by label for root to point to
>> /dev/md0 doesn't seem to matter much in itself. Should the backup config
>> be changed to not look for the root label link in /dev/disk but rather
>> looking at the mounts?
>>
> 
> Using the /dev/disk/by-label/root link is much easier :-)
> I'd have to look, but IIRC it is also used elsewhere. Verifying
> available disk space before update comes to mind.

Well, they are supposed to be there. I should mention that the only thing 
that does show up is the /dev/disk/by-path which points to the first drive 
on the first controller and the name of the link all start with pci.

This only recently started happening. One of my raid test boxes which I had 
a November build running on until last weekend, did not exhibit this 
behavior. I hadn't studied in detail the new udev rules which come with the 
newest mdadm yet. 

-- 
Dave Studeman
http://www.raqcop.com 

On 2014-01-03 15:28, David W Studeman wrote:

>>> Olaf, did you ever get to test one of the Geos units from Traverse? To
>>> anyone else reading, the Traverse Geos platform has the solos-pci built
>>> into the motherboard and can be had in single or dual adsl config but not
>>> the quad port like the pci mammoth I have to play with. Traverse has been
>>> better about updated firmware lately for their cards they spun off to
>>> Rocksolid.
>>
>> Yes, worked properly.
>> Special version of the ADSL firmware is required to deal with the Annex
>> version we run here in Germany.
>
> If I remember correctly you are in Annex M territory?

Annex B, due to the large number of ISDN users 
http://en.wikipedia.org/wiki/Integrated_Services_Digital_Network#Germany


Olaf

On 2014-01-06 11:17, David W Studeman wrote:
> David W Studeman wrote:
>
>
>>
>> I'm a bit baffled as to what could have changed to cause any of these
>> things?
>
> Update. I see that udev creates the links but the one thing that changed
> recently is the mdadm upgrade and the udev rules created by it. Mdadm now
> has two rules sets rather than one from previous versions and there are
> quite a few differences. This was a major mdadm change from the previous
> version according to the documentation.

Yes, the display in status.cgi is related but differently. Fixed in #7203.


> At this point, not having the links by label for root to point to /dev/md0
> doesn't seem to matter much in itself. Should the backup config be changed
> to not look for the root label link in /dev/disk but rather looking at the
> mounts?
>

Using the /dev/disk/by-label/root link is much easier :-)
I'd have to look, but IIRC it is also used elsewhere. Verifying 
available disk space before update comes to mind.


Olaf

As I mentioned in a previous thread, for some reason I get a red background 
on the raid status section even though raid is clean with both devices.

Running sysinfo as shown results in this:

root@raqcop:~ # /usr/local/bin/sysinfo --raid=md0
/dev/md0:
        Version : 0.90
  Creation Time : Mon Jan  6 01:23:54 2014
     Raid Level : raid1
     Array Size : 1819584 (1777.24 MiB 1863.25 MB)
  Used Dev Size : 1819584 (1777.24 MiB 1863.25 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Jan  7 17:00:35 2014
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 51f47334:f8d0e1e5:2553d4d9:c3d8d998
         Events : 0.20

    Number   Major   Minor   RaidDevice State
       0       3        1        0      active sync   /dev/hda1
       1      22        1        1      active sync   /dev/hdc1

Does anything there look off? I attached a tiny screen shot of this:
-- 
Dave Studeman
http://www.raqcop.com 

David W Studeman wrote:


> 
> I'm a bit baffled as to what could have changed to cause any of these
> things?

Update. I see that udev creates the links but the one thing that changed 
recently is the mdadm upgrade and the udev rules created by it. Mdadm now 
has two rules sets rather than one from previous versions and there are 
quite a few differences. This was a major mdadm change from the previous 
version according to the documentation.

At this point, not having the links by label for root to point to /dev/md0 
doesn't seem to matter much in itself. Should the backup config be changed 
to not look for the root label link in /dev/disk but rather looking at the 
mounts?  

-- 
Dave Studeman
http://www.raqcop.com 

For whatever reason, many of my raid installs while testing recent builds, 
do not put links in /dev/disk/by-label for either root or varlog_comp. The 
program ipcobkcfg looks for the link to root and if it does not exist, it 
fails to mount a usb flash drive for backup. If I manually create the link 
to root pointing to /dev/md0 in this case, the backup works fine. This does 
not happen in single disk installs for either Cobalt or normal PC installs.

I have noticed also for quite some time that /dev/.mdadm doesn't exist in 
Cobalt Raqcop installs only, on a normal PC install it does exist after 
first boot. On Raqcop, running mdadm --assemble --scan creates this 
directory. Since we start udev manually on a Cobalt due to lack of initrd, 
is there somewhere where I should be doing anything with mdadm manually in 
rc.sysinit? Does it matter?

Even without the links, running mount -l shows:

proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev type tmpfs (rw,mode=755)
/dev/md0 on / type ext3 (rw,noatime) [root]
/dev/md1 on /var/log_compressed type ext3 (rw,noatime) [varlog_comp]
tmpfs on /tmp type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec)
tmpfs on /ram type tmpfs (rw,size=50%)

There is no obvious detriment to the system running as far as I can see.

On my 2.0.6 Flash Raid daily firewall, all this exists properly and there is 
no red background for raid in a clean array. In recent builds, both Raqcop 
and normal PC installs show red even though it is clean and not degraded.

I'm a bit baffled as to what could have changed to cause any of these 
things? 

--
Dave Studeman
http://www.raqcop.com