ipcop-devel Mailing List for IPCop Firewall

I just saw the post on the User list about the -I option missing on 
ping in 1.4.0 and verified it myself.  This option is vital to those 
of us trying to keep VPNs up with dynamic DNS addresses.  I have 
contributed scripts and advice on how to do this over the years.

Basically, in my configuration I have lots of DDNS addressable VPN 
gateways.  I also have cron jobs running every few minutes to check 
if the IPCop gateway can ping all its corresponding gateways over the 
VPN using the -I interface option.  If it can't, the script issues 
ipsec commands to restart the connection and in doing so resolve the 
changed DDNS name.

I realize this doesn't happen too often (every 6 months or so) for 
each gateway, but as you multiply the number of gateways in your VPN, 
the changes occur more frequently.  Since each gateway connects to 
all others, this quickly becomes unmanageable.

Assume 12 IPCop gateways, that means one will change each month.  So 
once a month someone would have to log into 12 gateways via ssh and 
restart the connection.  But wait, an external user can't get to the 
gateway whose address changed unless port 222 is open to the net.  In 
fact, restarting the changed connection on all the other gateways 
won't work till I restart the connection on the changed gateway. 
It's easiest if I have a user on the changed gateway reboot it.  Try 
doing that at 2 AM.  Now try this with more gateways.

I have have checked the freeswan documentation and it looks like it's 
possible to force an extra connection between the two gateways only 
for ping purposes, but this seems like a lot of work.  Any chance of 
getting the -I option back?

Harry

> > > IPcop version 1.4/1.5 are using the grub boot manager instead of lilo
> > > in v1.3. We have build a v1.4 based on a cvs snapshot.
> > > After creating the flash image, its hangs in grub loading stage2...
> > > This one has been a pain to try to solve, for me anyway. I have no 
> good
> > answer. I currently have to put the CF in a reader, and rerun
> > grub to get it to work.
> > > Maybe someone else has an answer. I hope.


> I have committed a possible fix to cvs. 


I use mkflash :) I tried the new script and it produces the same 
behavior as the one in beta 3. Specifically grub echos out "Loading 
stage 2" repeatedly
for about 5 seconds and then random chanracters apear on my screen. (On 
a VM
Ware machine it just halts and says the machine segfaulted.)

I saw what you added (0x8000). I monkeyed with the install line a bit 
because
I though that maybe grub couldn't find 
/mnt/flash/boot/grub/e2fs_stage1_5 (which if you run find at that point 
it says it can't). I changed it to /grub/e2fs_stage1_5 which find said 
it could find but that just really messed
things up. The VMWare machine just crashed without dumping anything to 
the screen. I didn't bother trying it on a real machine. I don't know 
enough about grub to do anything but monkey.


> > Then after you rerun grub and get it to boot, you may find that
> > /etc/fstab needs to be modified (replace harddisk2 with harddisk3). 
> Only
> > one other person besides myself has recently mentioned this, so 
> maybe it
> > is something specific to certain systems(?), or maybe no one uses
> > mkflash. 


> This has been fixed in the same script.


I didn't encounter this problem. I load my CF images by booting off a 
Knoppix
CD, mounting a share from my network, and writing the image from that 
with dd.
I also didn't rerun grub from a floppy or anything, I just gave up.


> > Additionally, the ramdisk_size kernel parameter does not get
> > set up in grub.conf. The corresponding sed line in mkflash needed to be
> > modified to work for me, otherwise it simply wouldn't be added.


> This has also been fixed.


Yup, this works for me now.

LMK when the rest of the stuff is fixed ;)

Matt

I have made a howto about, how you can build IPCop on a windows 
workstation with w2k or XP (using Cooperative Linux).

The howto is stored as pdf, rtf and ooo-sxw on

http://home.tiscali.dk/m-c/ipcop/index.htm

It is too large to put into the building-howto, but a link from that and 
a more "official" store, than the link above might be
a solution.


--
mvh
Morten Christensen

The IPCop cvs wants mod_ssl 2.8.17 for Apache.

2.8.17 was replaced by 2.8.18 on may 27.


-- 
mvh
Morten Christensen
*
*** <http://httpd.apache.org/dist/httpd/apache_1.3.31.tar.gz>

Hi everyone,
 
I am using 1.4b3 with red, green, blue, and orange. 
 
green:  192.168.1.254
blue:    192.168.10.1
 
the blue pc is: 192.168.10.2 running xp home.
 
After making sure computer in blue can access internet, I enable vpn on blue and config and roadwarrior connection for one of the pc on Blue (192.168.10.2).  
I then install ssh sentinel 1.3 on 192.168.10.2 and setup the client and then enable the connection.  Wow, now I can ping any pc in green network.
 
But when I try to access internet, it is not working.  Is it supppose to be like this? Can I still use internet on this blue machine? how?
 
After I disable the vpn link from sentinel, of course I can't ping the green network after disabling vpn.  I can't go online either.  To solve this prblem, I have to manually goto ipcop and diable the vpn connection.  Then reboot the pc to have the internet back.
Anyone know why this happen?
 
Thanks,
Jonthan
 


Retail POS system, Inc.
		
---------------------------------
Do you Yahoo!?
Friends.  Fun. Try the all-new Yahoo! Messenger

Hello

I already tried twice in ip-user to bring up this problem,
but never got any response.


Is it really no problem when pakets from the internal LAN
which should be wrapped by IPsec and routed thru a VPN are going
(as clear text?) into the internet(!) only because the VPN is down?

Is that such really a stupid question? Please tell what i miss.


When i traceroute from my LAN to the the other LAN,
connected by a IPsec VPN i suddenly got responses from
my providers routers(!) until his(!) boarder router
is reached.
This occured (reproducible) when the VPN was down!
(The other end had a bad ethernet cable between a Cisco ADSL Modem and IPcop)


Tried that with 1.3 but i assume that problem may still exist on 1.4.



>>>  -------------------------------
>>>  NAME: home
>>>
>>>  RH IP ADDRESS: x.x.x.22
>>>  RH GATEWAY   : x.x.x.1
>>>  RH SUBNET    : 192.168.0.0/24
>>>
>>>  LH IP ADDRESS: y.y.126.99
>>>  LH GATEWAY   : %defaultroute
>>>  LH SUBNET    : 192.168.1.0/24
>>>  -------------------------------
>>>

>In almost all cases you should be able to use %defaultroute on both
>sides (actually you don't have to specify GATEWAY for the remote side
>of the interface, but you can leave it in to make life simpler.)

Is it really wise to use "%defaultroute" ?
I found my VPN pakets tumbling as clear text thru the internet(!) 
when the VPN tunnel was down! 
I think that's not the expected behaviour of a paket filtering firewall, or?


How can i force IPcop to terminate the tunnel always 
on itself, regardless if the according VPN is up or not?


Would:

-------------------------------
NAME: home

RH IP ADDRESS: x.x.x.x
RH GATEWAY   : 192.168.0.1
RH SUBNET    : 192.168.0.0/24

LH IP ADDRESS: y.y.y.y
LH GATEWAY   : 192.168.1.1 
LH SUBNET    : 192.168.1.0/24
-------------------------------

help/work?


If, why is the "dangerous" "%defaultroute" recommended?

Rainer---<=====>                         Vertraulich
             //  
           //                              
         <=====>--------------ocholl, Kiel, Germany ------------

SGksDQpyZWdhcmRpbmcgdGhlIGFib3ZlIG1lbnRpb25lZCBmaWxlLCBJIGNhbm5vdCBmaW5kIGl0
IGVpdGhlciwgaWYgc29tZW9uZSBoYXMgYSBsaW5rIHRvIGl0IEknZCBiZSBncmF0ZWZ1bCBmb3Ig
aXQuDQpBbHNvIGlmIGFueW9uZSBoYXMgYSBsaW5rIHRvIGdsaWJjLTIuMy4yLXByb3BvbGljZS1n
dWFyZC1mdW5jdGlvbnMtMS5wYXRjaCBJJ2QgYmUgZ3JhdGVmdWwgZm9yIHRoYXQgYXMgd2VsbCAo
bm8gbWF0dGVyIHdoaWNoIHZlcnNpb24gSSB0cnkgdG8gYnVpbGQsIHRoZXJlIGp1c3QgaGFzIHRv
IGJlIG9uZSBmaWxlIG1pc3NpbmchKQ0KIA0KVGhhbmtzIGZvciBhbnkgaGVscA0KIA0KV2lsbCBP
dHRld2VsbA0K

----- Original Message -----
From: "Alan Hourihane" <al...@fa...>
To: "Richard McGrath" <ric...@bi...>
Cc: <ipc...@li...>
Sent: Wednesday, May 26, 2004 2:14 PM
Subject: Re: [IPCop-devel] IPCop never reconnects when pppd exits


Your patch solve the issue 'Address already in use' I have seen with
Connexant PCI card.
When pppd stop, there is still a
"May 30 08:47:33 ipcop kernel: vcc_sock_destruct: rmem leakage (-1538208
bytes) detected."
 but reconnection work fine now

The same sort of message 'rmem leakage' (but with positive value) should be
corrected with the speedtouch usb with the patch on 2.4.27.
I have to test applying the speedtouch patch.

ipcop 1.4.b3

I have setup a couple DMZ pinholes, however I am unable to connect from my
orange server to my green server over those ports.  When I do a iptables
-L there is nothing listed in the DMZHOLES section.  Is this not the
section that should show the dmz pinholes?  Also, does ipcop allow orange
computers to query dns from ipcop?

Thanks
Chris

-- 
If builders built houses the way programmers built programs, the first
woodpecker to come along would destroy civilization.
   -- Gerald Weinberg

Wayland Sothcott wrote:
>>However I am getting tired of trying to get you guys to sit up &
>>listen. At the rate people are taking up Wireless connections here
>>in Melbourne, there will be very few left on dial-up in a few years.
>>Wisp connections are now approaching that of ADSL! and are
>>particularly popular with games/linux/geek type users because of the
>>2Mbit speed in both directions. And there are no blocked ports. And
>>to top that the cost is cheaper than ADSL and comparable to dial-up.
>>At this time there are no other router/firewall products catering to
>>wisp users, hence since mentioning my efforts on a newsgroup I am
>>inundated with mail daily enquiring on my progress.
>>
>>Do I tell them IPCop is not interested in wisp users?
>>-- 
>>grumpy regards,
>>Lindsay
>>-------------------------------------------------------
> You tell 'em Lindsay,
> 
> WISPs are the future of Broadband. Who wants to be tied to BT? IPCop will
> really benifit from supporting WISP connections. I have tried to get people
> to do IPCop for Satellite to no avail, no linux drivers in IPCop for sat
> cards.
> 
> Regards,
> Wayland.
> 

G'day Wayland,
Thx for your support. And, yes, I agree.

Satellite would be a bigger problem because it uses different
interfaces for up and down, etc, etc. I do believe the developers
are quietly working on that atm, I may be wrong.
Satellite here is considered too expensive, even to many who only
have that option available. Personally I think satellite should be
subsidized for remote communities.
Hey, maybe one day I'll be competent enough to assist :-)
-- 
cheers,
Lindsay

> >
> However I am getting tired of trying to get you guys to sit up &
> listen. At the rate people are taking up Wireless connections here
> in Melbourne, there will be very few left on dial-up in a few years.
> Wisp connections are now approaching that of ADSL! and are
> particularly popular with games/linux/geek type users because of the
> 2Mbit speed in both directions. And there are no blocked ports. And
> to top that the cost is cheaper than ADSL and comparable to dial-up.
> At this time there are no other router/firewall products catering to
> wisp users, hence since mentioning my efforts on a newsgroup I am
> inundated with mail daily enquiring on my progress.
>
> Do I tell them IPCop is not interested in wisp users?
> -- 
> grumpy regards,
> Lindsay
>
>
>
> -------------------------------------------------------
You tell 'em Lindsay,

WISPs are the future of Broadband. Who wants to be tied to BT? IPCop will
really benifit from supporting WISP connections. I have tried to get people
to do IPCop for Satellite to no avail, no linux drivers in IPCop for sat
cards.

Regards,
Wayland.

G'day Gilles,
THANK YOU for your reply!
Gilles Espinasse wrote:
> Selon build <bu...@da...>:
> <snip>
>>However I am getting tired of trying to get you guys to sit up & 
>>listen. At the rate people are taking up Wireless connections here 
>>in Melbourne, there will be very few left on dial-up in a few years. 
>>Wisp connections are now approaching that of ADSL! and are 
>>particularly popular with games/linux/geek type users because of the 
>>2Mbit speed in both directions. And there are no blocked ports. And 
>>to top that the cost is cheaper than ADSL and comparable to dial-up. 
>>At this time there are no other router/firewall products catering to 
>>wisp users, hence since mentioning my efforts on a newsgroup I am 
>>inundated with mail daily enquiring on my progress.
>>
>>Do I tell them IPCop is not interested in wisp users?
>>-- 
>>grumpy regards,
>>Lindsay
>>
>>
> We may be interested to integrate the change you propose if it look coherent 
> and working. But at this time, we are more in the mood to remove any existing 
> bug than to add new features.
> And there is some still now even most of the remaining problem are not inherent 
> to the scripts we wrote but may come from the source packages we add in IPCop 
> or are due to bugs related to how ISP connect and disconnect us.

I wasn't expecting you to integrate any mods I might suggest for 
quite some time. I was hoping if I made an addon for 1.4 I might 
convince you of the merits of integrating it into 1.5.

> We ask you some questions where I don't remember we had the answers
> Have you tested in V1.4.0b3 or better a later build from CVS by yourself?

I did reply to you explaining that I don't have my debian box 
running atm, so I can't build it but will look asap.

> If you have a route to add after the connection is up, in the IPCop manner, it 
> should be done in rc.updatered (wich is launched by ip-up), if it is before the 
> connection was up, it is in rc.red.

That's it! THANK YOU! I now have something to work with.

> I don't understand why the 'active' value is not set in your case because every 
> time ip-up run, 'active' is set.

I don't know either but now I can investigate that tooo! (this is great)

> You look to have understood how the setting work, so please describe what you 
> want to do, the change you have done to do it and a report to what is not 
> working.

I will investigate with the above and gladly report back to you.

> a diff -Nur is a good way to show us the changes you have done.

I'm not sure what a diff-Nur is but I'll do a google & see if I can 
surprise you.

Gilles, THANK YOU VERY VERY MUCH. I'll be in touch.
-- 
cheers,
Lindsay

ja...@gu... wrote:
>>I've attached a RAR'ed Rich Text File of how I get my ipcop to connect.
>>(I'm using it now).
>>The problem with this is, ipcop doesn't know it's there so I can't 
>>administer it through the web interface, only SSH.
> 
> 
> Well congrats!!!  Web Interface is not working on green?  Maybe a 
> route issue. or you are not using https://<ipcop>:445

I can open the web interface, however ipcop does not have provision 
to control this type of connection. Other wisp users do not know how 
to SSH into a box and configure it. They need this to be integrated 
in to the setup disc.
>  
> 
>>I am VERY willing to try doing the mods myself but I need some 
>>direction from an experienced person.
>>
>>I think the easiest way to cater for as many users and wisps as 
>>possible is to edit pppsetup.cgi to have checkboxes for all the 
>>(pptpclient & pppd) options and also the ability for the user to add 
>>routes after the interface is up.
>>
>>Then add instructions for various wisps as required.
>>
>>PLEASE, if I misunderstood your question, let me know.
> 
> 
> Actaully was not questions to you but what I was trying to find out 
> to see which were allowed and which were not.
> 
> Why not add your information to www.ipcop.org so others can learn to. 
>  Just add yourself into twiki and away you go.

[sigh] I have posted to the mailing list many many times in the last 
6 months with little success. Seems they are not interested in 
emerging technologies or new developers.
> 
> jjackb
> 
> 
However I am getting tired of trying to get you guys to sit up & 
listen. At the rate people are taking up Wireless connections here 
in Melbourne, there will be very few left on dial-up in a few years. 
Wisp connections are now approaching that of ADSL! and are 
particularly popular with games/linux/geek type users because of the 
2Mbit speed in both directions. And there are no blocked ports. And 
to top that the cost is cheaper than ADSL and comparable to dial-up. 
At this time there are no other router/firewall products catering to 
wisp users, hence since mentioning my efforts on a newsgroup I am 
inundated with mail daily enquiring on my progress.

Do I tell them IPCop is not interested in wisp users?
-- 
grumpy regards,
Lindsay

IPCop v140b3

Severed reported a bug in vpnmain.cgi (Bugs item #960131) that the drop down
menu in the config screen that selects Left or Right wasn't working. He
could never save an entry as 'Right', only as 'Left'.

I've committed a fix (hopefully) to CVS, but anyone who's experiencing
similar difficulties, and who'd like to hack their system to test it, the
changes can be found here:

http://marc.theaimsgroup.com/?l=ipcop-cvs&m=108550480613197&w=2

Eric

My problem is solved. The explanation is on
http://groups.google.fr/groups?dq=&hl=fr&lr=&ie=UTF-8&threadm=xoavvfijmmio.f
sf%40sun.com&prev=/groups%3Fhl%3Dfr%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.prot
ocols.ppp

It was not related to the plugin. I had the same problem with pppoa3.
I change pppsetup.cgi to allow two more options (only pap, only chap ) and
insert '-chap' when pap is selected and '-pap' when it is chap selected.
When I choose pap, it work all the times I try. And it fail every time chap
is selected with PPPoA.

I will now be able to test your change.

I give a quick look at the solution proposed by James Carlson (consider
authentification is successfull when IPCP is received).
I understand where the code is (main.c line 1034 and after) but my C skill
is a bit too fresh.

 
The sourceforge bug site shows 11 open bugs for 1.4beta. I would assume the
developers are still trying to get those closed before releasing another
beta.
 
--Dan
-----Original Message-----
From: Roy Walker [mailto:rw...@mi...]
Sent: Wednesday, May 26, 2004 1:00 PM
To: ipc...@li...
Subject: [IPCop-devel] Time to make final beta release?


The list seems to have quieted down.  I think it would be a good time for
the next (final?) beta release.  Anyone have any outstanding bugs that are
holding us up?
 
Roy


NOTICE: This e-mail message, including any attachments, is for the sole use
of the intended recipient(s). Any unauthorized review, use, disclosure or
distribution of this email or its contents is strictly prohibited. If you
are not the intended recipient, please contact the sender by reply mail and
destroy the original and all copies of the original message. 

The list seems to have quieted down.  I think it would be a good time
for the next (final?) beta release.  Anyone have any outstanding bugs
that are holding us up?
=20
Roy

Hi,

I am using the Green / Blue / Red configuration for IPCop 1.4.0B3 and 
can access the Internet (Red) both from Green and Blue (after 
activating Blue Access for my computer's MAC address).

However, I would like to increase the security of this setup as follows:

- restrict all access from Blue to VPN traffic exclusively
- combine VPN access control with MAC address verification if possible
- do not allow any access to Green from Blue, only to Red

As it stands now, I've set up a test VPN connection in IPCop and have 
managed to connect to it successfully. What further configuration 
changes would be required to achieve the setup mentioned above?

Thanks in advance,

Patrick

To really tell I'd need to see your messages from /var/log/messages.

Alan.

On Mon, May 24, 2004 at 09:39:03AM +1000, Richard McGrath wrote:
> Hi.
> 
> I am not sure if I am experiencing the same problem, but:  I have a ISDN 
> modem connected via a USB cable, and while it connects OK, once it is 
> disconnected (manually or otherwise) I have to to pull out the USB cable 
> and put it in again before I can connect again.
> 
> With 1.4 b3, the log messages were saying something about not being able 
> to get a lock on the USB device (I think).  With the latest beta there 
> are no such messages, and it still does not re-connect.  Is it possible 
> that this is being cause by the bug you are describing?
> 
> Thanks,
> Richard
> 
> Nick Hutt wrote:
> 
> >---- Original Message ----- 
> >From: "Alan Hourihane" <al...@fa...>
> >To: "Nick Hutt" <mir...@bt...>
> >Cc: <ipc...@li...>
> >Sent: Sunday, May 23, 2004 10:15 PM
> >Subject: Re: [IPCop-devel] IPCop never reconnects when pppd exits
> >
> >
> >
> >>On Sun, May 23, 2004 at 09:46:16PM +0100, Nick Hutt wrote:
> >>
> >>>---- Original Message ----- 
> >>>From: "Alan Hourihane" <al...@fa...>
> >>>To: <ipc...@li...>
> >>>Sent: Sunday, May 23, 2004 7:05 PM
> >>>Subject: [IPCop-devel] IPCop never reconnects when pppd exits
> >>>
> >>>
> >>>
> >>>>Developers,
> >>>>
> >>>>I've discovered exactly why my PPPoA connection to my ISP never ever
> >>>>reconnects when something happens to pppd to signal it's exit.
> >>>>
> >>>>The problems stems from the ip-down script which tries to run
> >>>>the /etc/rc.d/rc.connectioncheck script. Someone obviously tried to
> >>>>workaround the problem by 'backgrouding' the process but this cannot
> >
> >work.
> >
> >>>>The 'system' command forks the child process, but when the end of
> >>>>ip-down is reached it will automatically wait for all child processes
> >>>>to complete. At which point the rc.connectioncheck tries to
> >>>>run /etc/rc.d/rc.red to start the connection again and will ultimately
> >>>>fail. This is because pppd believes that ip-down has not yet completed
> >
> >and
> >
> >>>>therefore holds the PPPoA connection modules in-use until ip-down
> >>>
> >>>completes.
> >>>
> >>>>The effect of this is that pppd tries to connect and receives the
> >
> >message
> >
> >>>>'Address already in use' and will always fail.
> >>>>
> >>>>I've modified my build to put the rc.connectioncheck into the crontab
> >>>>for every one minute checks, but I've also been looking at the
> >>>>opportunity to run wvdial or diald to do the re-dial for me. As one
> >>>>minute checks seem excessive, but necessary to maintain the
> >
> >connection.
> >
> >>>>I've no doubt that this problem is affecting other users and not just
> >>>>PPPoA users.
> >>>>
> >>>>So which direction to jump...
> >>>>
> >>>>1. Remove rc.connectioncheck from ip-down, and put it in the
> >
> >crontab...
> >
> >>>or...
> >>>
> >>>>2. Implement a form of wvdial/diald.
> >>>>
> >>>>Preference ??
> >>>>
> >>>>Personally - my preference is for option 1... it's easier for 1.4.
> >>>>
> >>>>Alan.
> >>>
> >>>Hi Alan,
> >>>
> >>>You absolutely sure the problem is with rc.connectioncheck?
> >>
> >>Like I said in the original email rc.connectioncheck cannot be in the
> >>ip-down script as it will try to bring up the connection before it's
> >>been cleanly shutdown. And, yes, I'm positive. I've checked,
> >
> >double-checked
> >
> >>and triple-checked.
> >>
> >>Alan.
> >
> >
> >Alan,
> >
> >As far as I can tell rc.connectioncheck does wait for the connection to be
> >shut down, it checks for the presence of /var/run/ppp-ipcop.pid, if this
> >disappears then pppd has exited, perhaps try adding a sleep for a few
> >seconds to make sure it's exited properly before the restart.
> >
> >Just for the record, both boxes I have running rc.connectioncheck do use
> >pppoa and I don't see this problem on either box that you are having which
> >is why I asked if you were sure it was rc.connectioncheck, I didn't mean to
> >offend you or insult you at all.  Perhaps I don't have a problem because 
> >the
> >version I am running is very different, my ip-down file is also different 
> >it
> >just runs rc.connectioncheck in the background there is no check to see if
> >keepconnected is present as this check is performed by rc.connectioncheck.
> >If you would like to try out the version I use let me know and I will make
> >the neccesary modifications to make it run correctly on a 1.4 box.
> >
> >One more thought, running rc.connectioncheck in a crontab job may be rather
> >dangerous as you could end up with multiple instances of it running and 
> >have
> >it attempt to restart the connection multiple times.
> >
> >Regards
> >
> >Nick
> >
> >
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: Oracle 10g
> >>Get certified on the hottest thing ever to hit the market... Oracle 10g.
> >>Take an Oracle 10g class now, and we'll give you the exam FREE.
> >>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> >>_______________________________________________
> >>IPCop-devel mailing list
> >>IPC...@li...
> >>https://lists.sourceforge.net/lists/listinfo/ipcop-devel
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: Oracle 10g
> >Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> >Take an Oracle 10g class now, and we'll give you the exam FREE.
> >http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> >_______________________________________________
> >IPCop-devel mailing list
> >IPC...@li...
> >https://lists.sourceforge.net/lists/listinfo/ipcop-devel
> >
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

On Tue, May 25, 2004 at 08:57:24AM +0200, Gilles Espinasse wrote:
> 
> ----- Original Message -----
> From: "Alan Hourihane" <al...@fa...>
> To: <ipc...@li...>
> Sent: Tuesday, May 25, 2004 1:23 AM
> Subject: [IPCop-devel] pppd's persist option
> 
> 
> > After the tribulations with pppd and my PPPoA connection, I've just been
> > looking at a friends and found problems with pppd's 'persist' option.
> >
> > It seems to me the really isn't a need for us to pass this option to
> > pppd anymore and it's causing us more grief than necessary. The whole
> > idea of pppd's 'persist' option is for pppd to re-spin in it's main()
> > loop and re-establish connections. Although I'd really like to fix pppd
> > it seems that we don't have to. The whole point of our rc.connectioncheck
> > script allows the persistency of the connection to be maintained
> regardless of
> > using pppd's option.
> >
> > In the case of Nick Hutts' problem with pppd hanging, I've seen it happen
> > with using the 'persist' option, and the problems disappear when removing
> it.
> >
> > I'm proposing the patch below, if someone would like to test it, who is
> > suffering from reconnection/pppd problems using a persist connection - I'd
> > like to hear their outcome. It certainly seems to be working a lot better
> > here.
> >
> > Has anyone objections to this ??
> >
> > Alan.
> >
> 
> At this time, I have problem to only connect with pppoatm.so plugin, so
> reconnection is a secondary problem for me.
> I don't know exactly where the problem come from but it work with pppoa3 and
> a speedtouch usb.
> 
> The rp-pppoe plugin work fine with the persist option, with pppoa too.
> 
> A problem I have previously seen with {pppoa3|pppoa|pppoatm.so} is that pppd
> do not respawn after lcp timeout error if the first connection was not gone
> to the up level.
> 
> I don't know why but connection identification look to depend of what ppp
> client I use.
> It is mostly (80%) CHAP with PPPoA protocol but mostly PAP with PPPoE (chap
> is refused a few times).
> 
> One of my log with pppoatm plugin look like that (192.168.254.254 is the
> defaut gaetway address I receive)

Also,

Try adding the 'default-asyncmap' to the flags passed to pppd for your
pppoatm connection.

Let us know.

Alan.

On Tue, May 25, 2004 at 08:57:24AM +0200, Gilles Espinasse wrote:
> 
> ----- Original Message -----
> From: "Alan Hourihane" <al...@fa...>
> To: <ipc...@li...>
> Sent: Tuesday, May 25, 2004 1:23 AM
> Subject: [IPCop-devel] pppd's persist option
> 
> 
> > After the tribulations with pppd and my PPPoA connection, I've just been
> > looking at a friends and found problems with pppd's 'persist' option.
> >
> > It seems to me the really isn't a need for us to pass this option to
> > pppd anymore and it's causing us more grief than necessary. The whole
> > idea of pppd's 'persist' option is for pppd to re-spin in it's main()
> > loop and re-establish connections. Although I'd really like to fix pppd
> > it seems that we don't have to. The whole point of our rc.connectioncheck
> > script allows the persistency of the connection to be maintained
> regardless of
> > using pppd's option.
> >
> > In the case of Nick Hutts' problem with pppd hanging, I've seen it happen
> > with using the 'persist' option, and the problems disappear when removing
> it.
> >
> > I'm proposing the patch below, if someone would like to test it, who is
> > suffering from reconnection/pppd problems using a persist connection - I'd
> > like to hear their outcome. It certainly seems to be working a lot better
> > here.
> >
> > Has anyone objections to this ??
> >
> > Alan.
> >
> 
> At this time, I have problem to only connect with pppoatm.so plugin, so
> reconnection is a secondary problem for me.
> I don't know exactly where the problem come from but it work with pppoa3 and
> a speedtouch usb.
> 
> The rp-pppoe plugin work fine with the persist option, with pppoa too.
> 
> A problem I have previously seen with {pppoa3|pppoa|pppoatm.so} is that pppd
> do not respawn after lcp timeout error if the first connection was not gone
> to the up level.
 
That's exactly the problem I'm talking about. It does try to respawn but
fails to bring up the connection. Removing the 'persist' option, stops
pppd from trying to bring it up again, and allows our rc.connectioncheck
script to bring it up for us.

> I don't know why but connection identification look to depend of what ppp
> client I use.
> It is mostly (80%) CHAP with PPPoA protocol but mostly PAP with PPPoE (chap
> is refused a few times).
> 
> One of my log with pppoatm plugin look like that (192.168.254.254 is the
> defaut gaetway address I receive)

From the look of these, your machine starts to receive IPCP packets before
finishing the CHAP authentication with your ISP.

Do you have a log of when it works to compare it with ?

Alan.

Can we please have it so clients on GREEN can use their own Windows VPN to
connect to servers on the outside?

Regards,
Wayland

----- Original Message -----
From: "Alan Hourihane" <al...@fa...>
To: <ipc...@li...>
Sent: Tuesday, May 25, 2004 1:23 AM
Subject: [IPCop-devel] pppd's persist option


> After the tribulations with pppd and my PPPoA connection, I've just been
> looking at a friends and found problems with pppd's 'persist' option.
>
> It seems to me the really isn't a need for us to pass this option to
> pppd anymore and it's causing us more grief than necessary. The whole
> idea of pppd's 'persist' option is for pppd to re-spin in it's main()
> loop and re-establish connections. Although I'd really like to fix pppd
> it seems that we don't have to. The whole point of our rc.connectioncheck
> script allows the persistency of the connection to be maintained
regardless of
> using pppd's option.
>
> In the case of Nick Hutts' problem with pppd hanging, I've seen it happen
> with using the 'persist' option, and the problems disappear when removing
it.
>
> I'm proposing the patch below, if someone would like to test it, who is
> suffering from reconnection/pppd problems using a persist connection - I'd
> like to hear their outcome. It certainly seems to be working a lot better
> here.
>
> Has anyone objections to this ??
>
> Alan.
>

At this time, I have problem to only connect with pppoatm.so plugin, so
reconnection is a secondary problem for me.
I don't know exactly where the problem come from but it work with pppoa3 and
a speedtouch usb.

The rp-pppoe plugin work fine with the persist option, with pppoa too.

A problem I have previously seen with {pppoa3|pppoa|pppoatm.so} is that pppd
do not respawn after lcp timeout error if the first connection was not gone
to the up level.

I don't know why but connection identification look to depend of what ppp
client I use.
It is mostly (80%) CHAP with PPPoA protocol but mostly PAP with PPPoE (chap
is refused a few times).

One of my log with pppoatm plugin look like that (192.168.254.254 is the
defaut gaetway address I receive)
May 25 07:39:50 ipcop pppd[28660]: PPPoATM setdevname_pppoatm - SUCCESS:8.35
May 25 07:39:50 ipcop pppd[28661]: pppd 2.4.2 started by root, uid 0
May 25 07:39:50 ipcop pppd[28661]: using channel 32
May 25 07:39:50 ipcop pppd[28661]: Using interface ppp0
May 25 07:39:50 ipcop pppd[28661]: Connect: ppp0 <--> 8.35
May 25 07:39:50 ipcop pppd[28661]: sent [LCP ConfReq id=0x1 <magic
0xe6c8fc22>]
May 25 07:39:50 ipcop pppd[28661]: rcvd [LCP ConfReq id=0x39 <mru 9178>
<auth chap MD5> <magic 0x4a082a76>]
May 25 07:39:50 ipcop pppd[28661]: sent [LCP ConfAck id=0x39 <mru 9178>
<auth chap MD5> <magic 0x4a082a76>]
May 25 07:39:53 ipcop pppd[28661]: sent [LCP ConfReq id=0x1 <magic
0xe6c8fc22>]
May 25 07:39:53 ipcop pppd[28661]: rcvd [LCP ConfAck id=0x1 <magic
0xe6c8fc22>]
May 25 07:39:53 ipcop pppd[28661]: sent [LCP EchoReq id=0x0
magic=0xe6c8fc22]
May 25 07:39:53 ipcop pppd[28661]: rcvd [CHAP Challenge id=0x63
<4c751c0304320c8aae226f8c060522a6>, name = "BSSGW113"]
May 25 07:39:53 ipcop pppd[28661]: sent [CHAP Response id=0x63
<998df2ae8982a6534444c976f69a9732>, name = "mylogin@freeadsl"]
May 25 07:39:53 ipcop pppd[28661]: rcvd [LCP EchoRep id=0x0
magic=0x4a082a76]
May 25 07:39:54 ipcop pppd[28661]: rcvd [LCP EchoReq id=0x1 magic=0x4a082a76
8a ae 22 6f]
May 25 07:39:54 ipcop pppd[28661]: sent [LCP EchoRep id=0x1 magic=0xe6c8fc22
05 05 06 4a]
May 25 07:39:55 ipcop pppd[28661]: rcvd [IPCP ConfReq id=0x2 <addr
192.168.254.254>]
May 25 07:39:55 ipcop pppd[28661]: discarding proto 0x8021 in phase 5
May 25 07:39:57 ipcop pppd[28661]: rcvd [IPCP ConfReq id=0x3 <addr
192.168.254.254>]
May 25 07:39:57 ipcop pppd[28661]: discarding proto 0x8021 in phase 5
May 25 07:39:59 ipcop pppd[28661]: rcvd [IPCP ConfReq id=0x4 <addr
192.168.254.254>]
May 25 07:39:59 ipcop pppd[28661]: discarding proto 0x8021 in phase 5
May 25 07:40:01 ipcop pppd[28661]: rcvd [IPCP ConfReq id=0x5 <addr
192.168.254.254>]
May 25 07:40:01 ipcop pppd[28661]: discarding proto 0x8021 in phase 5
May 25 07:40:03 ipcop pppd[28661]: rcvd [IPCP ConfReq id=0x6 <addr
192.168.254.254>]
May 25 07:40:03 ipcop pppd[28661]: discarding proto 0x8021 in phase 5
May 25 07:40:05 ipcop pppd[28661]: rcvd [IPCP ConfReq id=0x7 <addr
192.168.254.254>]
May 25 07:40:05 ipcop pppd[28661]: discarding proto 0x8021 in phase 5
May 25 07:40:07 ipcop pppd[28661]: rcvd [IPCP ConfReq id=0x8 <addr
192.168.254.254>]
May 25 07:40:07 ipcop pppd[28661]: discarding proto 0x8021 in phase 5
May 25 07:40:09 ipcop pppd[28661]: rcvd [IPCP ConfReq id=0x9 <addr
192.168.254.254>]
May 25 07:40:09 ipcop pppd[28661]: discarding proto 0x8021 in phase 5
May 25 07:40:11 ipcop pppd[28661]: rcvd [IPCP ConfReq id=0xa <addr
192.168.254.254>]
May 25 07:40:11 ipcop pppd[28661]: discarding proto 0x8021 in phase 5
May 25 07:40:13 ipcop pppd[28661]: sent [LCP EchoReq id=0x1
magic=0xe6c8fc22]
May 25 07:40:13 ipcop pppd[28661]: rcvd [LCP EchoRep id=0x1
magic=0x4a082a76]
May 25 07:40:33 ipcop pppd[28661]: sent [LCP EchoReq id=0x2
magic=0xe6c8fc22]
May 25 07:40:33 ipcop pppd[28661]: rcvd [LCP EchoRep id=0x2
magic=0x4a082a76]

> -----Original Message-----
> From: Wayland Sothcott [mailto:wa...@so...]
> Sent: Monday, May 24, 2004 1:11 AM
> To: Trevor Benson; ipcop-devel
> Subject: Re: [IPCop-devel] L2TP
>=20
>=20
> ----- Original Message -----
> From: "Trevor Benson" <tb...@a-...>
> To: "ipcop-devel" <ipc...@li...>
> Sent: Friday, May 21, 2004 3:29 AM
> Subject: [IPCop-devel] L2TP
>=20
>=20
> I have completed a modification of the vpn subsystem to include L2TP
> passthrough for Microsoft servers, a bit late to try and submit for
1.4,
> but I will make this into an Addon package for 1.4 when released, and
> hope for inclusion into 1.5.0.
>=20
> Is there anyone interested, or needing to test something like this
that
> has a Microsoft domain behind IPCop and would like to use the native
2k
> or XP clients for VPN?  Let me know and I will shoot you a test copy.
>=20
> Trevor
>=20
>=20
>=20
> -------------------------------------------------------
>=20
>=20
> Trevor,
>=20
> When you say behind IP-Cop, do you mean the server is on GREEN and the
> client is on RED?

Yes, or at least the current version is a Microsoft (or other) server
running L2TP behind ipcop inside the green network.

> I have users on GREEN wishing to connect to their various offices
outside
> on
> the Internet somewhere. This does not work with V1.3 unless I have my
ZOOM
> X4 in NAT mode. Native RED ADSL in IP-Cop 1.3 will not allow this.
>=20
> Regards,
> Wayland.
>=20

Not sure on the clients and protocols, so cant say much for the users
problems :)

Trevor

Sorry, wrong keystroke...

> > can anyone tell me why I can find no link to firewalladdons.sourceforge.net
> > on the IPCop Wiki?
> 
> Becuase noone added it.  Twiki is an enviroment that allows anyone to 
> add any thing.  So if firewalladdons wanted to link, they could.
> 
> > Or am I just blind?
> 
> Look at the edit option at the bottom of the page.