ipcop-devel Mailing List for IPCop Firewall

I have followed this thread with interest but perhaps just removing all
the md5sums from the mirrors and relying on the source for the md5sum
would alleviate most of the worries about manipulation with the minimum
of effort.

The only problem with this is that if the source goes down people cannot
get a reference MD5SUM.

Out of interest I know that this type of attack is easily possible but
how often has it been documented as actually happening? 


Mark (fat) 

On Monday 29 April 2002 05:18 am, you wrote:

> Either you get the MD5 or you get the PGP sig/key from the one true
> IPCop site, or you trust the mirror, or you are screwed.  Whether
> it's an MD5 or a PGP signature you are checking doesn't seem to make
> any difference to me...

There are five primary goals of encryption technology:

Confidentiality
Authentication
Nonrepudiation
Integrity
Authorization

Confidentiality and Authorization are not issues here, which only 
leaves three things to be addressed.

Authentication is addressed when, by use of usernames, passwords, 
special codes, or other devices, a third party introduces the people or 
businesses involved in a transaction, and documents that both parties 
are whom they say they are and have the necessary credentials to 
continue with the transaction. 

Nonrepudiation is the assurance that both parties to a transaction 
remain honest about their actions and not dispute their agreement.

Integrity refers to the assurance or guarantee that business 
information has not been altered while in transit or in storage.

MD5 checksums only address Integrety.

You don't get the PGP key from the IPCop site. You get it from a public 
keyserver, from a trusted source, or directly from the owner. It can be 
assigned a level of trust. You can converse privately with the author 
to get a fingerprint of the key to insure you got the key they created.

PGP provides Authentication and Nonrepudiation. Authentication is the 
basic thing that Gareth is talking here and in the role we are talking 
about, nonrepudiation is the difference between having a piece of paper 
telling something is fact and having a signed contract that has been 
notarized stating that fact.

On Monday 29 April 2002 06:21 pm, you wrote:

> To put it in another view, how many people use MD5 hashes in their
> emails to validate it is what they sent compared to GPG/PGP
> signatures. 

> MD5 guarantees it is as the sender intended,

Validation.

> but has no implication of the identity of the sender.

Non-Repudiation.

Both are required for trust.

[Changed the subject to more accurately reflect topic :-)]

Well it looks like I'm in the minority here, but I'll give it one more go!

> But that's silly -- You snag the MD5 from the original site -- Who
> would trust and MD5 from a mirror site?...
Agree that you should get the MD5 from the original site. So should mirror
sites even have references to MD5 values - or just reference the main site?

> But you have to get the correct signature key thingie, and a hacker
> could just sign their own package, right?
They could sign it, but only with their key. So you would see that it was
signed by 'i_m...@ev...', not 'ma...@do...' . One of the most
fundamental aspects of Public Key Encryption (PKE) is that your private key
does not get compromised. If someone gets hold of your private key the game
is over!

GPG still has the traditional  problem with key distribution normally
associated with public key encryption. But having multiple key servers
allows people to have a relative degree of faith that the application is
genuine. Users can use GPG to directly contact a key server and  retrieve
the public key of the distributor, and can then validate the package works.

> I mean, if you're going to trust the PGP sig/key you get from the
> mirror site, you're really in the same boat, aren't you?
The difference is that only one entity can generate a signature. So the evil
person cant create a signature imitating a authorized IPCop distributor.

To put it in another view, how many people use MD5 hashes in their emails to
validate it is what they sent compared to GPG/PGP signatures. MD5 guarantees
it is as the sender intended, but has no implication of the identity of the
sender.

> But in the end, it's just as easy to fake a GPG key as it is to fake an
MD5.
> Unless you personally hand over the key, it's worth just as much as MD5.
> The only difference would be that the GPG key is the same for all
downloads
> and the MD5 has to be checked every time
If done correctly it is much harder to fake a GPG key, your degree of trust
is altered based on how you get your key and how many signatures are on your
key - hand delivery with passport is obviously the most secure :-)). For our
purposes if someone is going to hijack all of the keyservers to return back
a bogus public key then the game would be significantly biased! But in
reality I would say that a GPG signature is still more secure than a
straight hash. Obviously nothing is perfect, and unless you received the key
through a trusted secure route (with a couple of known signatures on) and
you public keyring is secure from tampering there will always be some
opportunity for someone to be mischievous.

Personally I would suggest we follow a practice similar to the Apache
project ( http://www.apache.org/dist/httpd/) that also uses PGP keys to sign
their releases.

Anyhow I apologize for the ramble :-) This is certainly something that is
not critical yet, although I do believe it would help with installer trusts
:-)

Gareth

----- Original Message -----
From: "Richard Lynch" <ce...@l-...>
To: <ipc...@li...>
Sent: Monday, April 29, 2002 10:18 AM
Subject: Re: [IPCop-devel] Re: [IPCop-user] Fast download mirror


> >Don't worry I wouldn't try to attempt to alter an application and make
that
> >fit a MD5 hash!
> >
> >To me the key difference is that a MD5 hash has no ownership associated
with
> >it. So if I were an evil cracker and I had access to a distribution site
> >then I could easily alter the package and regenerate the MD5 key. Unless
> >someone is validating the MD5 on the mirror site is the same as the
primary
> >site, it will all match and the install would happen.
>
> But that's silly -- You snag the MD5 from the original site -- Who
> would trust and MD5 from a mirror site?...
>
> >However in the GPG case I couldn't alter the package and still have a
valid
> >GPG signature of the 'build-meister'.
> >
> >Its still a little 'swings and roundabouts' but GPG at least would tie
you
> >to a identity, and a little more security. Its not necessarily something
> >that joe public would religiously do. But for the more paranoid its a
little
> >more comforting :-)
>
> But you have to get the correct signature key thingie, and a hacker
> could just sign their own package, right?
>
> I mean, if you're going to trust the PGP sig/key you get from the
> mirror site, you're really in the same boat, aren't you?
>
> Where's the gain?  Forgive me if I'm just being stupid here...
>
> Either you get the MD5 or you get the PGP sig/key from the one true
> IPCop site, or you trust the mirror, or you are screwed.  Whether
> it's an MD5 or a PGP signature you are checking doesn't seem to make
> any difference to me...
>
> I suppose it's a *BIT* easier to have the PGP key/sig you get *ONCE*
> from the primary source, and then can re-use it, but how long can it
> take you to get an MD5, even on dial-up from the other side of the
> planet?
> --
> Got Music? http://l-i-e.com/artists.htm
>
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>

>Don't worry I wouldn't try to attempt to alter an application and make that
>fit a MD5 hash!
>
>To me the key difference is that a MD5 hash has no ownership associated with
>it. So if I were an evil cracker and I had access to a distribution site
>then I could easily alter the package and regenerate the MD5 key. Unless
>someone is validating the MD5 on the mirror site is the same as the primary
>site, it will all match and the install would happen.

But that's silly -- You snag the MD5 from the original site -- Who 
would trust and MD5 from a mirror site?...

>However in the GPG case I couldn't alter the package and still have a valid
>GPG signature of the 'build-meister'.
>
>Its still a little 'swings and roundabouts' but GPG at least would tie you
>to a identity, and a little more security. Its not necessarily something
>that joe public would religiously do. But for the more paranoid its a little
>more comforting :-)

But you have to get the correct signature key thingie, and a hacker 
could just sign their own package, right?

I mean, if you're going to trust the PGP sig/key you get from the 
mirror site, you're really in the same boat, aren't you?

Where's the gain?  Forgive me if I'm just being stupid here...

Either you get the MD5 or you get the PGP sig/key from the one true 
IPCop site, or you trust the mirror, or you are screwed.  Whether 
it's an MD5 or a PGP signature you are checking doesn't seem to make 
any difference to me...

I suppose it's a *BIT* easier to have the PGP key/sig you get *ONCE* 
from the primary source, and then can re-use it, but how long can it 
take you to get an MD5, even on dial-up from the other side of the 
planet?
-- 
Got Music? http://l-i-e.com/artists.htm

Hi,

> To me the key difference is that a MD5 hash has no ownership associated
with
> it. So if I were an evil cracker and I had access to a distribution site
> then I could easily alter the package and regenerate the MD5 key. Unless
> someone is validating the MD5 on the mirror site is the same as the
primary
> site, it will all match and the install would happen.
>
> However in the GPG case I couldn't alter the package and still have a
valid
> GPG signature of the 'build-meister'.
>
> Its still a little 'swings and roundabouts' but GPG at least would tie you
> to a identity, and a little more security. Its not necessarily something
> that joe public would religiously do. But for the more paranoid its a
little
> more comforting :-)

But in the end, it's just as easy to fake a GPG key as it is to fake an MD5.
Unless you personally hand over the key, it's worth just as much as MD5.
The only difference would be that the GPG key is the same for all downloads
and the MD5 has to be checked every time.

Kind regards,

        Mark

Attached are an updated proxy.cgi (goes in /home/httpd/cgi-bin/ ) and an
updated en.pl and de.pl (they go in /var/ipcop/langs/ ). Be sure that you
save them with the correct permissions (755) for the proxy.cgi and 644 for
the en.pl and de.pl.

The changes to the proxy.cgi allow the user to enter a username and password
in the web interface to allow authentication to  a parent proxy. If the two
new fields are left blank, a username and password are not used (as before).

If anyone is running the beta and has access to a authenticated proxy, I
would love any feedback.

Sam Snow

Don't worry I wouldn't try to attempt to alter an application and make that
fit a MD5 hash!

To me the key difference is that a MD5 hash has no ownership associated with
it. So if I were an evil cracker and I had access to a distribution site
then I could easily alter the package and regenerate the MD5 key. Unless
someone is validating the MD5 on the mirror site is the same as the primary
site, it will all match and the install would happen.

However in the GPG case I couldn't alter the package and still have a valid
GPG signature of the 'build-meister'.

Its still a little 'swings and roundabouts' but GPG at least would tie you
to a identity, and a little more security. Its not necessarily something
that joe public would religiously do. But for the more paranoid its a little
more comforting :-)

Gareth
----- Original Message -----
From: "Richard Lynch" <ce...@l-...>
To: <ipc...@li...>
Sent: Sunday, April 28, 2002 1:21 AM
Subject: Re: [IPCop-devel] Re: [IPCop-user] Fast download mirror


> >This is why I think we should not only supply the MD5 hash, but also a
GPG
> >signature indicating the package is valid. This way we can really protect
> >to fake a GPG signature!
>
> How does a GPG signature increase security?
>
> I defy you to come up with the same MD5 hash for an altered release.
>
> The PGP keyring trust system is too easy for users to screw up.
>
> [shrug]
>
> Just my opinion.
> --
> Got Music? http://l-i-e.com/artists.htm
>
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>

How heavy of browsing were you doing at the time - or 
did it happen during an idle period?

To be honest, I havn't seen the 'Unable to load 
interpreter' message for YEARS.  In the past, it was 
always related to memory and file handles.

cat /proc/sys/fs/file-nr.  Are those three numbers 
pretty close to each other?  If so, you're running low 
on handles.  I don't know about the 2.4 kernel, but 
the 2.2 kernel doesn't free them once they are 
allocated.

To increase them try: echo #### > /proc/sys/fs/file-max

...where #### is the new max file handles.  My default 
was 4096 and my system hadn't come close to touching 
that.  You might want to bump it by 50%.

Mike

>This is why I think we should not only supply the MD5 hash, but also a GPG
>signature indicating the package is valid. This way we can really protect
>to fake a GPG signature!

How does a GPG signature increase security?

I defy you to come up with the same MD5 hash for an altered release.

The PGP keyring trust system is too easy for users to screw up.

[shrug]

Just my opinion.
-- 
Got Music? http://l-i-e.com/artists.htm

Just wondering if anyone else is seeing this problem;

I installed beta2 from MD5 verified ISO CD about a week ago and it has wo=
rked=20
very well, (except for a one issue that I've nearly fixed).
Yesterday, Squid started giving problems, it would stop passing traffice =
for=20
about 5 mins and all would be fine.
After checking the GUI, I see that the service is stopped when traffic is=
 not=20
flowing and I find these errors in the "Kernel log":

13:31:01 kernel Unable to load interpreter /lib/ld-linux.so.2
13:31:02 kernel Unable to load interpreter /lib/ld-linux.so.2
13:51:24 kernel Unable to load interpreter /lib/ld-linux.so.2
13:53:41 kernel VM: killing process squid

But as I said, it re-starts itself after about 5 mins (sometimes 10). =20
Don't know if this is related or not but 5 hours earlier my DSL line went=
 down=20
for maintenance and pppd (pppoe) was not running but the GUI thought it w=
as=20
and I couldn't "Disconnect" or even ip-down/ifconfig down the ppp0 interf=
ace=20
("interface does not exist")

This is a Red/Green/Orange Beta2 with the one fix applied, installed from=
 CD=20
from MD5 summed ISO on 540M HDD in Compaq Prolinea (100Mhz Pentium Classi=
c)=20
with 96M RAM.  Squid was enabled as transparent proxy with default settin=
gs.

Rob

I will check it... im not sure why it wouldnt.

I will keep you posted.

Jeremy

----------------------------------------------------------------------------
-----------
Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or responsible
for delivery of the message to such person), you may NOT copy, forward,
CC, BCC or deliver this message to anyone. In such case, you should destroy
this message and kindly notify the sender by reply email. Please advise
immediately
if you do not consent to Internet email for messages of this kind. Opinions,
conclusions
and other information in this message do not relate to the anyone other than
the sender
----- Original Message -----
From: "Alan Rouse" <al...@ro...>
To: <ipc...@li...>
Sent: Friday, April 26, 2002 4:58 AM
Subject: [IPCop-devel] Canadian mirror


> The ipcop 0.1.1 download from the Canadian mirror does not match the md5
> sum posted on the web page.
>
> The download from the UK mirror does match.
>
>
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>

The ipcop 0.1.1 download from the Canadian mirror does not match the md5 
sum posted on the web page.

The download from the UK mirror does match.

Michael A. Gütlbauer wrote:

>Placebo Rulez wrote:
>  
>
>>I noticed that Ipcop 0.1.1 fixes 5 only checks the first 8 characters of a
>>password when you logon.
>>    
>>
>
>Isn't this normal under Linux?
>
Yes, and no. The 'Classical' unix password system had this limitation.
It was replaced / augmented by using md5 hashes for the password encryption.
This allows you to have a longer password.

>I noticed that phenomenon a few years ago
>on my very first Suse distribution and never thought about it ...
>
>Michael
>
>_______________________________________________
>IPCop-devel mailing list
>IPC...@li...
>https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>
>
>  
>

Placebo Rulez wrote:
> I noticed that Ipcop 0.1.1 fixes 5 only checks the first 8 characters of a
> password when you logon.

Isn't this normal under Linux? I noticed that phenomenon a few years ago
on my very first Suse distribution and never thought about it ...

Michael

Hi,

> I've read in several threads a lot about this beta but could not find
> any page, where the differences to 0.1.1final are described. There's
> absolutely no information about that on www.ipcop.org. How about a
> subpage which deals with the current beta releases?

Actually, I like to keep the beta's inside the devel list.  There's a lot 
of risk involved if regular users start installing the beta.  There have 
been some major bugs (for example with VPN's or not being able to dialup).

Anyway, read here:
http://marc.theaimsgroup.com/?l=ipcop-devel&m=101722102316734&w=2
http://marc.theaimsgroup.com/?l=ipcop-devel&m=101956574920183&w=2

Kind regards,

	Mark
-- 
***************************************************************
* |\    /|      |  /|  /       Mark Wormgoor                  *
* | \  / |      | / | /        mailto:ma...@wo...       *
* |  \/  |ark   |/  |/ormgoor  http://www.wormgoor.com/mark/  *
***************************************************************

Hallo!

I've read in several threads a lot about this beta but could not find
any page, where the differences to 0.1.1final are described. There's
absolutely no information about that on www.ipcop.org. How about a
subpage which deals with the current beta releases?

Cheers,
--=20
Michael A. G=FCtlbauer
http://www.guetlbauer.com/

Antworten bitte ausschlie=DFlich in der NG!

On Wednesday 24 April 2002 03:40 am, you wrote:
> This is why I think we should not only supply the MD5 hash, but also
> a GPG signature indicating the package is valid. This way we can
> really protect from the suspect sites from distributing suspect hashs
> too. Its much harder to fake a GPG signature!
>
> This would then enable specific core members to gatekeep the release,
> and essentially certify it has passed their checks etc.

Sounds good to me. Too bad we are so far apart. Tough to hold a key 
signing...

Hi ipcop-development-team,

I noticed that Ipcop 0.1.1 fixes 5 only checks the first 8 characters of a 
password when you logon.
I checked the following ways to logon:

Web interface:
admin

SSH:
root
setup

They all accept a password with only the fist 8 characters correct, so if my 
password would be 1234567890 i will let me in when i type 12345678, also 
12345678xxxx and 1234567890xxxxxxx would get me in. 1234567 and 1234567x did 
not work.

I have tried the following passwords
3com1#rulez
appel1234
1q2w3e4r5t
ipcop8passwbug

I did not check any other version of Ipcop.
I also did not check it directly on the box. its kinda buried :o)

I you need any more information you can contact me at 
pla...@ho...

Joost Bakker
(a paranoid sysadmin who thinks that 8 characters is reasonably save but 12 
or more would be alot better.)

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Hi John,

Answers below...

At 11:10 25/04/02 +0100, you wrote:
>On Wed, Apr 24, 2002 at 09:15:14AM +1000, Guy Ellis wrote:
> > Hi John,
> >
> > I saw your post on IPCop-devel. I wrote the ibod changes, and found that
> > both channels came up ok for me and several other beta testers.
>
>Good, that means that it's just a local problem for us (unmetered ISDN
>dialup to Demon Internet in the UK).

Maybe.


> > One thing I did find is that the first channel needed to connect before 
> the
> > second call is attempted, otherwise ML-PPP lcp negotiation seems to fail.
> >
> > So perhaps you have experienced a timing problem. Perhaps we need to 
> wait a
> > bit longer before bringing up the second channel.
>
>The first channel is dialing up and getting an IP address in about
>3 seconds (see syslog excerpt below). The second channel does not
>even try to startup, it's as if the "isdnctrl addlink" command is
>not bonding them together.
>
>One question that I not sure on - when we run "isdnctrl addlink ippp0",
>how does it know that the channel we want to add is ippp1 ?

ippp1 is defined as a slave device for ippp0


> > Please try changing the sleep value (currently 5 seconds) to say 10 
> seconds
> > with the original script and see if that fixes the problem.
>
>It's now a live system that works well with the extra dial commands, so
>I'm a bit relectant to change it too much (at least inside office hours).
>I'll let you know if I get more information.

Please try the original script when you get a chance, and send me the log.

We can then compare it to your logs below.

Cheers,

  -Guy.


> > You could also check /var/log/messages to what is actually going on.
>
>OK, here's a short excerpt:
>----------------------------------------------------------------------
>Apr 23 20:35:06 gateway ipcop: Dialing Demon - Dual ISDN.
>Apr 23 20:35:06 gateway ipppd: info: no CHAP secret entry for this user!
>Apr 23 20:35:06 gateway ipppd[464]: Found 2 devices: ,
>Apr 23 20:35:06 gateway ipppd[465]: ipppd i2.2.12 (isdn4linux version of 
>pppd by MH) started
>Apr 23 20:35:06 gateway ipppd[465]: init_unit: 0
>Apr 23 20:35:06 gateway ipppd[465]: Connect[0]: /dev/ippp0, fd: 5
>Apr 23 20:35:06 gateway ipppd[465]: init_unit: 1
>Apr 23 20:35:06 gateway ipppd[465]: Connect[1]: /dev/ippp1, fd: 6
>Apr 23 20:35:12 gateway kernel: ippp0: dialing 1 08440416677...
>Apr 23 20:35:14 gateway kernel: isdn_net: ippp0 connected
>Apr 23 20:35:14 gateway ipppd[465]: Local number: 01234771023, Remote 
>number: 08440416677, Type: outgoing
>Apr 23 20:35:14 gateway ipppd[465]: PHASE_WAIT -> PHASE_ESTABLISHED, 
>ifunit: 0, linkunit: 0, fd: 5
>Apr 23 20:35:14 gateway ipppd[465]: Remote message:
>Apr 23 20:35:14 gateway ipppd[465]: MPPP negotiation, He: Yes We: Yes
>Apr 23 20:35:14 gateway ipppd[465]: CCP enabled! Trying CCP.
>Apr 23 20:35:14 gateway ipppd[465]: CCP: got ccp-unit 0 for link 0 
>(Compression Control Protocol)
>Apr 23 20:35:14 gateway ipppd[465]: ccp_resetci!
>Apr 23 20:35:15 gateway ipppd[465]: ccp_resetci!
>Apr 23 20:35:15 gateway ipppd[465]: local  IP address 193.195.20.90
>Apr 23 20:35:15 gateway ipppd[465]: remote IP address 158.152.1.222
>Apr 23 20:35:15 gateway ipcop: PPP has gone up on ippp0
>----------------------------------------------------------------------
>
>With the extra dial commands I get the following:
>----------------------------------------------------------------------
>Apr 23 16:08:02 gateway ipcop: Dialing Demon - Dual ISDN.
>Apr 23 16:08:02 gateway ipppd: info: no CHAP secret entry for this user!
>Apr 23 16:08:02 gateway ipppd[30638]: Found 2 devices: ,
>Apr 23 16:08:02 gateway ipppd[30639]: ipppd i2.2.12 (isdn4linux version of 
>pppd by MH) started
>Apr 23 16:08:02 gateway ipppd[30639]: init_unit: 0
>Apr 23 16:08:02 gateway ipppd[30639]: Connect[0]: /dev/ippp0, fd: 8
>Apr 23 16:08:02 gateway ipppd[30639]: init_unit: 1
>Apr 23 16:08:02 gateway ipppd[30639]: Connect[1]: /dev/ippp1, fd: 9
>Apr 23 16:08:03 gateway kernel: ippp0: dialing 1 08440416677...
>Apr 23 16:08:05 gateway kernel: isdn_net: ippp0 connected
>Apr 23 16:08:05 gateway ipppd[30639]: Local number: 01234771023, Remote 
>number: 08440416677, Type: outgoing
>Apr 23 16:08:05 gateway ipppd[30639]: PHASE_WAIT -> PHASE_ESTABLISHED, 
>ifunit: 0, linkunit: 0, fd: 8
>Apr 23 16:08:05 gateway ipppd[30639]: Remote message:
>Apr 23 16:08:05 gateway ipppd[30639]: MPPP negotiation, He: Yes We: Yes
>Apr 23 16:08:05 gateway ipppd[30639]: CCP enabled! Trying CCP.
>Apr 23 16:08:05 gateway ipppd[30639]: CCP: got ccp-unit 0 for link 0 
>(Compression Control Protocol)
>Apr 23 16:08:05 gateway ipppd[30639]: ccp_resetci!
>Apr 23 16:08:05 gateway ipppd[30639]: ccp_resetci!
>Apr 23 16:08:06 gateway ipppd[30639]: local  IP address 193.195.20.90
>Apr 23 16:08:06 gateway ipppd[30639]: remote IP address 158.152.1.222
>Apr 23 16:08:06 gateway ipcop: PPP has gone up on ippp0
>
>
>Apr 23 16:08:08 gateway kernel: ippp1: dialing 1 08440416677...
>Apr 23 16:08:10 gateway ipppd[30639]: Local number: , Remote number: 
>08440416677, Type: outgoing
>Apr 23 16:08:10 gateway ipppd[30639]: PHASE_WAIT -> PHASE_ESTABLISHED, 
>ifunit: 1, linkunit: 1, fd: 9
>Apr 23 16:08:10 gateway kernel: isdn_net: ippp1 connected
>Apr 23 16:08:10 gateway ipppd[30639]: ioctl(SIOCSIFMTU): No such device, 7 
>ippp1 1500.
>Apr 23 16:08:10 gateway ipppd[30639]: Remote message:
>Apr 23 16:08:10 gateway ipppd[30639]: MPPP negotiation, He: Yes We: Yes
>Apr 23 16:08:10 gateway ipppd[30639]: ipppd[1]: discr: 2
>Apr 23 16:08:10 gateway ipppd[30639]: ipppd[1]: passed 1
>Apr 23 16:08:10 gateway ipppd[30639]: ipppd[1]: passed 2
>Apr 23 16:08:10 gateway ipppd[30639]: ipppd[1]: pap/chap-check passed
>Apr 23 16:08:10 gateway ipppd[30639]: ok, found a valid bundle with linkunit 0
>Apr 23 16:08:10 gateway ipppd[30639]: bundle: 0
>----------------------------------------------------------------------
>
> > Please advise.
> >
> > Cheers,
> >
> >   - Guy.
>
>
> >
> >
> > At 04:34 pm 23/04/2002 +0100, you wrote:
> > >Hi
> > >We've been testing the dual channel ISDN option with no Bandwidth on 
> Demand
> > >because Demon's "Super Showroom" keeps dropping both lines when
> > >
> > >Anyway with the new ppp-on script only the first channel was dialling up
> > >and "isdnctrl status ippp1" showed that the second channel was still down.
> > >
> > >I modified ppp-on to force a dialup after the "addlink" isdnctrl command
> > >using:
> > >         system('/usr/sbin/isdnctrl', 'dial', 'ippp1');
> > >and the now both lines come up and stay up.
> > >
> > >A short patch file is attached.
> > >
> > >--
> > >John Edwards
> > >sh...@co...
> >
> > ------------------------------------------------------------------
> > Guy Ellis
> > gu...@tr...
> >
> > Traverse Technologies
> > ABN 98 078 657 324
> > 652 Smith St.,
> > Clifton Hill, Victoria, 3068
> > AUSTRALIA
> > http://www.traverse.com.au
> > Tel (+613) 9486 7775
> > Fax (+613) 9482 7754
> > Mobile 0419 398 234
> > ------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > IPCop-devel mailing list
> > IPC...@li...
> > https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>
>--
>John Edwards
>sh...@co...

*****************************************************************
Guy Ellis
gu...@tr...

Traverse Technologies Australia
652 Smith St.,
Clifton Hill, Vic. 3068,
Australia.
http://www.traverse.com.au

Tel (613) 9486 7775
Fax (613) 9482 7754
Mobile 0419 398 234

*****************************************************************

Hi all,

..root's prompt should, imntho, be " # ".  Is "$" in ipcop.
Bug in bottom line of '/etc/profile'.

.._all_ lines starting "PS1='\[\033[" etc, broke at the 72'nd character,
and will need to be put back home on one line.

..so: root@gw/etc$tail -n 1 profile-0
PS1='\[\033[1;33m\]\u\[\033[1;37m\]@\[\033[1;32m\]\h\[\033[1;31m\]\w\[\
033[1;36m\]$\[\033[0m\]'
           A
           |
..bug: "$" should read "\$" to create an acceptable 
"#" for root, like: "root@gw/etc#".

..diff: root@gw:/etc # diff profile-0 profile

root@gw:~ # cd /etc/
root@gw:/etc # diff profile-0 profile
47c47
<
PS1='\[\033[1;33m\]\u\[\033[1;37m\]@\[\033[1;32m\]\h\[\033[1;31m\]\w\[\
033[1;36m\]$\[\033[0m\]'
---
> 
PS1='\[\033[1;33m\]\u\[\033[1;37m\]@\[\033[1;32m\]\h\[\033[1;37m\]:\[
\033[1;31m\]\w \[\033[1;36m\]\$ \[\033[0m\]'
root@gw:/etc #

..as usual, I got carried away: "root@gw:/etc # ", where the ":"
is ':\[\033[1;31m\]' and " " is ' ', like "\w " and "\$ ".  ;-)
-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

On Wed, Apr 24, 2002 at 09:15:14AM +1000, Guy Ellis wrote:
> Hi John,
> 
> I saw your post on IPCop-devel. I wrote the ibod changes, and found that 
> both channels came up ok for me and several other beta testers.

Good, that means that it's just a local problem for us (unmetered ISDN 
dialup to Demon Internet in the UK).

> One thing I did find is that the first channel needed to connect before the 
> second call is attempted, otherwise ML-PPP lcp negotiation seems to fail.
> 
> So perhaps you have experienced a timing problem. Perhaps we need to wait a 
> bit longer before bringing up the second channel.

The first channel is dialing up and getting an IP address in about 
3 seconds (see syslog excerpt below). The second channel does not 
even try to startup, it's as if the "isdnctrl addlink" command is 
not bonding them together.

One question that I not sure on - when we run "isdnctrl addlink ippp0", 
how does it know that the channel we want to add is ippp1 ?

> Please try changing the sleep value (currently 5 seconds) to say 10 seconds 
> with the original script and see if that fixes the problem.

It's now a live system that works well with the extra dial commands, so 
I'm a bit relectant to change it too much (at least inside office hours). 
I'll let you know if I get more information.

> You could also check /var/log/messages to what is actually going on.

OK, here's a short excerpt:
----------------------------------------------------------------------
Apr 23 20:35:06 gateway ipcop: Dialing Demon - Dual ISDN.
Apr 23 20:35:06 gateway ipppd: info: no CHAP secret entry for this user! 
Apr 23 20:35:06 gateway ipppd[464]: Found 2 devices: , 
Apr 23 20:35:06 gateway ipppd[465]: ipppd i2.2.12 (isdn4linux version of pppd by MH) started
Apr 23 20:35:06 gateway ipppd[465]: init_unit: 0 
Apr 23 20:35:06 gateway ipppd[465]: Connect[0]: /dev/ippp0, fd: 5
Apr 23 20:35:06 gateway ipppd[465]: init_unit: 1 
Apr 23 20:35:06 gateway ipppd[465]: Connect[1]: /dev/ippp1, fd: 6
Apr 23 20:35:12 gateway kernel: ippp0: dialing 1 08440416677...
Apr 23 20:35:14 gateway kernel: isdn_net: ippp0 connected
Apr 23 20:35:14 gateway ipppd[465]: Local number: 01234771023, Remote number: 08440416677, Type: outgoing
Apr 23 20:35:14 gateway ipppd[465]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 5
Apr 23 20:35:14 gateway ipppd[465]: Remote message: 
Apr 23 20:35:14 gateway ipppd[465]: MPPP negotiation, He: Yes We: Yes
Apr 23 20:35:14 gateway ipppd[465]: CCP enabled! Trying CCP. 
Apr 23 20:35:14 gateway ipppd[465]: CCP: got ccp-unit 0 for link 0 (Compression Control Protocol)
Apr 23 20:35:14 gateway ipppd[465]: ccp_resetci! 
Apr 23 20:35:15 gateway ipppd[465]: ccp_resetci! 
Apr 23 20:35:15 gateway ipppd[465]: local  IP address 193.195.20.90
Apr 23 20:35:15 gateway ipppd[465]: remote IP address 158.152.1.222
Apr 23 20:35:15 gateway ipcop: PPP has gone up on ippp0
----------------------------------------------------------------------

With the extra dial commands I get the following:
----------------------------------------------------------------------
Apr 23 16:08:02 gateway ipcop: Dialing Demon - Dual ISDN.
Apr 23 16:08:02 gateway ipppd: info: no CHAP secret entry for this user! 
Apr 23 16:08:02 gateway ipppd[30638]: Found 2 devices: , 
Apr 23 16:08:02 gateway ipppd[30639]: ipppd i2.2.12 (isdn4linux version of pppd by MH) started
Apr 23 16:08:02 gateway ipppd[30639]: init_unit: 0 
Apr 23 16:08:02 gateway ipppd[30639]: Connect[0]: /dev/ippp0, fd: 8
Apr 23 16:08:02 gateway ipppd[30639]: init_unit: 1 
Apr 23 16:08:02 gateway ipppd[30639]: Connect[1]: /dev/ippp1, fd: 9
Apr 23 16:08:03 gateway kernel: ippp0: dialing 1 08440416677...
Apr 23 16:08:05 gateway kernel: isdn_net: ippp0 connected
Apr 23 16:08:05 gateway ipppd[30639]: Local number: 01234771023, Remote number: 08440416677, Type: outgoing
Apr 23 16:08:05 gateway ipppd[30639]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 8
Apr 23 16:08:05 gateway ipppd[30639]: Remote message: 
Apr 23 16:08:05 gateway ipppd[30639]: MPPP negotiation, He: Yes We: Yes
Apr 23 16:08:05 gateway ipppd[30639]: CCP enabled! Trying CCP. 
Apr 23 16:08:05 gateway ipppd[30639]: CCP: got ccp-unit 0 for link 0 (Compression Control Protocol)
Apr 23 16:08:05 gateway ipppd[30639]: ccp_resetci! 
Apr 23 16:08:05 gateway ipppd[30639]: ccp_resetci! 
Apr 23 16:08:06 gateway ipppd[30639]: local  IP address 193.195.20.90
Apr 23 16:08:06 gateway ipppd[30639]: remote IP address 158.152.1.222
Apr 23 16:08:06 gateway ipcop: PPP has gone up on ippp0


Apr 23 16:08:08 gateway kernel: ippp1: dialing 1 08440416677...
Apr 23 16:08:10 gateway ipppd[30639]: Local number: , Remote number: 08440416677, Type: outgoing
Apr 23 16:08:10 gateway ipppd[30639]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 1, linkunit: 1, fd: 9
Apr 23 16:08:10 gateway kernel: isdn_net: ippp1 connected
Apr 23 16:08:10 gateway ipppd[30639]: ioctl(SIOCSIFMTU): No such device, 7 ippp1 1500.
Apr 23 16:08:10 gateway ipppd[30639]: Remote message: 
Apr 23 16:08:10 gateway ipppd[30639]: MPPP negotiation, He: Yes We: Yes
Apr 23 16:08:10 gateway ipppd[30639]: ipppd[1]: discr: 2 
Apr 23 16:08:10 gateway ipppd[30639]: ipppd[1]: passed 1 
Apr 23 16:08:10 gateway ipppd[30639]: ipppd[1]: passed 2 
Apr 23 16:08:10 gateway ipppd[30639]: ipppd[1]: pap/chap-check passed 
Apr 23 16:08:10 gateway ipppd[30639]: ok, found a valid bundle with linkunit 0
Apr 23 16:08:10 gateway ipppd[30639]: bundle: 0
----------------------------------------------------------------------

> Please advise.
> 
> Cheers,
> 
>   - Guy.


> 
> 
> At 04:34 pm 23/04/2002 +0100, you wrote:
> >Hi
> >We've been testing the dual channel ISDN option with no Bandwidth on Demand
> >because Demon's "Super Showroom" keeps dropping both lines when
> >
> >Anyway with the new ppp-on script only the first channel was dialling up
> >and "isdnctrl status ippp1" showed that the second channel was still down.
> >
> >I modified ppp-on to force a dialup after the "addlink" isdnctrl command
> >using:
> >         system('/usr/sbin/isdnctrl', 'dial', 'ippp1');
> >and the now both lines come up and stay up.
> >
> >A short patch file is attached.
> >
> >--
> >John Edwards
> >sh...@co...
> 
> ------------------------------------------------------------------
> Guy Ellis
> gu...@tr...
> 
> Traverse Technologies
> ABN 98 078 657 324
> 652 Smith St.,
> Clifton Hill, Victoria, 3068
> AUSTRALIA
> http://www.traverse.com.au
> Tel (+613) 9486 7775
> Fax (+613) 9482 7754
> Mobile 0419 398 234
> ------------------------------------------------------------------
> 
> 
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

-- 
John Edwards
sh...@co...

I decided to test IPCop v0.1.2b2 + fixes1 on another machine (DSL connection
at the School Division Office).

Except for the VPN bug, all seems to work fine after the patch so far in my
limited testing.
I got my VPNs working again with the other IPCop 0.1.1 boxes thru the
workaround posted here in ipcop-devel.

I tried several different formats of the same MAC address with the following
results in the DHCP logs:
0050BA50184C          192.168.123.201     (no error message in DHCP log)
0050ba50184c          192.168.123.202     (value ba50184c exceeds max (255)
for precision)
00-50-BA-50-18-4C          192.168.123.203     (Bogus number:
00-50-BA-50-18-4C)
00-50-ba-50-18-4c          192.168.123.204     (Bogus number:
00-50-ba-50-18-4c)
00:50:BA:50:18:4C          192.168.123.205     (no error message in DHCP
log)
00:50:ba:50:18:4c          192.168.123.206     (preferred format, DHCP logs
appear this way)

Thus to keep things from appearing broken when in fact they likely aren't, I
would suggest that there should be some sanity checking of MAC address
formatting in the web interface?

Greg

Hi,

> i'm trying to build my own iso from scratch, but i fail while building
> the kernel. I got the following error message:

> I also found this error message in an very old mailing list from
> FreeSWAN, but there is no workaround. I'm using Mandrake 8.2 (after hard
> work i got i working, nearly ;-) I hope some one can help me.

What you really need here is kgcc.  This is usually provided by the egcs
package.  Install it from the cd and the kernel should compile just fine.

Kind regards,

            Mark

If you HTTP install IPCOP with only one NIC, the installation ends
saying "install not completed... be sure to log in as setup and
complete" (or words like that)

The problem is you have not set passwords so you cannot login as setup
(i.e. unknown password)

However the setup password defaults to blank.

I have only done this once. Will try to repeat when I get a moment.


Mark (fat)