ipcop-devel Mailing List for IPCop Firewall

On Sat, Jan 31, 2004 at 12:56:13PM -0800, Harry Goldschmitt wrote:
> Per Alan's suggestion, I'm trying to get familiar with 1.4.0 before 
> tackling the documentation.
> 
> It seems that creating a domain name for your local network is now 
> required.  The upgrade program then goes around and adds the domain 
> name to every host defined in the /etc/hosts file.  Why is this 
> mandatory?  What about users that have already added hosts with 
> domain names to the /etc/hosts file?  I'm managing way too many VPN 
> connections and lots of hostnames for various organizations in my 
> hosts file.  So running an install/upgrade will mess this up.
 
I don't know how the /etc/hosts file could have been modified, there's
no code in the upgrade-v130-v140.c file to attempt doing any of this
and I agree it would have been silly to modify /etc/hosts in this way,
but I can't see how it could be happening.

> I'm sure there's a good reason to add a mandatory domain name, other 
> than the default one for DHCP, but I've got to tell folks what it is. 
> Remember the Admin Manual says it's to make it easy for users to get 
> to the ISP's mail, web, etc. servers by continuing to enter www, etc. 
> for an address.

I'm not sure why it was made mandatory either, but I can see Mark did that.
 
> If a domain name will be required, rather than have lots of users 
> asking the question, "What's a good domain name for me to use?", why 
> don't we default to localdomain or some such in the text entry box?
 
Yup, it's not required - Mark ?

> I haven't had a chance to research this, so maybe someone can answer 
> this question - can a machine on the blue network access a machine on 
> the green network by default?

Yes.

Alan.

On Thu, 29 Jan 2004 09:31:39 +0100 (CET), 
Mark Wormgoor <ma...@wo...> wrote in message 
<Pin...@se...>:

> Hi,
> 
> IPCop 1.4.0 alpha10 is now up on SF.net for download
> (http://prdownloads.sourceforge.net/ipcop/).  This is a test release!
> It adds support for PCMCIA and we have upgraded ppp to 2.4.2. 
> However, PPP has been troublesome, both on 1.3.0 and with 2.4.2 also
> in the 1.4 series.  I have set debug and kdebug in rc.red (not in
> cvs).  This will cause lots of logging, but hopefully we can trace the
> problems. Most outstanding bugs have been fixed.
> 
> MD5: fb16ae92a5c5b2579a15e65ddb1a31cb  fcdsl-1.4.0a10.tgz
> MD5: bec69ca29333d2c6d3cf36369fc7837e  ipcop-1.4.0a10.iso
> MD5: c86951ffb34d53109f37016641992c37  ipcop-1.4.0a10.tar.gz

..this has the fixes Gilles came up with?

-- 
..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.

Per Alan's suggestion, I'm trying to get familiar with 1.4.0 before 
tackling the documentation.

It seems that creating a domain name for your local network is now 
required.  The upgrade program then goes around and adds the domain 
name to every host defined in the /etc/hosts file.  Why is this 
mandatory?  What about users that have already added hosts with 
domain names to the /etc/hosts file?  I'm managing way too many VPN 
connections and lots of hostnames for various organizations in my 
hosts file.  So running an install/upgrade will mess this up.

I'm sure there's a good reason to add a mandatory domain name, other 
than the default one for DHCP, but I've got to tell folks what it is. 
Remember the Admin Manual says it's to make it easy for users to get 
to the ISP's mail, web, etc. servers by continuing to enter www, etc. 
for an address.

If a domain name will be required, rather than have lots of users 
asking the question, "What's a good domain name for me to use?", why 
don't we default to localdomain or some such in the text entry box?

I haven't had a chance to research this, so maybe someone can answer 
this question - can a machine on the blue network access a machine on 
the green network by default?

Harry

ya...@ih...(Brendan Borlase)  31.01.04 17:49



>On Sat, 2004-01-31 at 12:51, Aaron Stevens wrote:
>> I'm asked to "enter domainname" in IPCop 1.4.0a10's installation.
>> What is this exactly?

>here's an example.. I'll use the name of my IPcop (you'll need a FIXED
>space font to make sense of my diagram!)

> gateway.sp0on.net
>	        ^-- domain suffix, in this case net.
>	   ^-- domain name, my domain is sp0on.
>    ^-- Hostname, in this case gateway.

>> I've searched the forums and mailing lists for its description and
>> found nothing.

>Cannot find the Wood, for the trees.. you see domains in every email
>address.. don't worry.. this making sense now??

And of what use is that Domainname for IPcop?
IPcop can't mail, IPcop it self does not have 
a full DNS.


>you can use something like ipcop.localnetwork if you don't own a
>domain name, 

Shouldn't be always such a "domain" ipcop.local or so?
IIRC announces the DHCPd the IP of a HostName to the local
DNS, so the computers on LAN are able to find themselves via DNS.
If you use your "world wide" domain, then you have a problem
if there are for example an ftp server named "ftp" "outside" on 
an allocated IP and an ftp server named "ftp" on the inside, private IP.



>and are _assigned_ a dns, or domain name by your isp..
>most DSL, cable etc connections will use the ISP's formated domain
>name by default.. clear as mud?

Rainer

ju...@kp...(Jurgen Johannsen)  30.01.04 17:31

Once upon a time "Jurgen Johannsen " shaped the electrons to say...

>Three problems in IPcop 1.4.0a10

>1. I have been unable to add more then one VPN connection.

>2. Also the swap space is 32MB in size, while my physical ram is
>512MB. I thought that Linux in general liked to have 1 or 2 times the
>RAM swap space.

No. That "rule of thumb" is from an epoch where "EMACS" were spelt
"Eight Megabytes of ram And Constantly Swapping".
(8MB were a lot(!) of RAM
Rember: the 80286 had only 24 Address lines! Sufficient
for as much as the unimaginable 16Meg of. RAM. Who will ever 
need or own more than 16MB RAM?)

Rainer

On Sun, 2004-02-01 at 00:49, Alan Hourihane wrote:
> Brendan,
> 
> O.k. I've realised what the trouble is and the fix I committed to
> load the modules when the PCMCIA controller is detected will fix it.
> 
> The reason is we were only loading the yenta_socket module when doing
> an HTTP install and not a CDROM one.

bingo.. nice one! heh, ironically, we'd never have caught this bug, this
early if I wasn't quite so slack.. indeed I was going to install via
HTTP to cut down on cd creation, but couldn't be bothered attaching the
floppy drive to my dell laptop :D

> Either build a CVS version or wait for a11.
> 

yep, found workaround as follows, which matches up nicely with the
fault. saves me building from CVS, as I have slow-poke dialup..

auto-probe once, "ok" the failed probe, switch to ttys3,

modprobe yenta_socket
modprobe xirc2ps_cs 

then switch back to ttys1 and fire auto-probe again.

the second modprobe is required for any non-cardbus, non-tulip xircom,
as although the module exists, it seems to not have made it into the
auto-probe routine.

> Thanks for testing and the valuable output logs.

np.. i've been watching this thing intently, and yes, as soon as the
above two modules are loaded (which cascades the rest) ipcop auto-probes
fine.

nothing else is required to work around the above bug in a10.

I appreciate your assistance.. and i've learnt a heap more about IPCOP
to boot.

-- 
regards,

Brendan Borlase

> yanis at ihug dot com dot au

Brendan,

O.k. I've realised what the trouble is and the fix I committed to
load the modules when the PCMCIA controller is detected will fix it.

The reason is we were only loading the yenta_socket module when doing
an HTTP install and not a CDROM one.

Either build a CVS version or wait for a11.

Thanks for testing and the valuable output logs.

Alan.

On Sat, Jan 31, 2004 at 11:56:26PM +1030, Brendan Borlase wrote:
> On Sat, 2004-01-31 at 22:49, Alan Hourihane wrote:
> > On Sat, Jan 31, 2004 at 10:31:52PM +1030, Brendan Borlase wrote:
> > > On Sat, 2004-01-31 at 21:32, Alan Hourihane wrote:
> > > --snip --
> > yenta_socket in 1.4a10 would only load when it's starting to auto-detect
> > the network cards. It wouldn't load it at boot up. I've made a change
> > in CVS which changes that, but it shouldn't make the slightest difference
> > for this scenario.
> > 
> > So, once you've hit auto-probe then you'll see yenta_socket appear in
> > the 'lsmod' output.
> > 
> 
> yes, it does. I see visual output for yenta - exact output, after tty1,
> and tty3 screens are loaded (same time as the first ipcop busybox screen
> has loaded, prompting for language) as follows:
> 
> Install program started.
> Initializing USB Controllers.
> Initializing PCMCIA Controllers.
> Detected PCMCIA Controller: yenta_socket
> 
> 
> if I do a cat /proc/modules I see:
> 
> usb-storage
> usbcore
> sr_mod
> sd_mod
> scsi_mod
> 
> nothing else.
 
You won't see yenta_socket until the auto-probe for the network card happens.
That's been changed in CVS.

> if I cat /proc/kmod, there is no mention of anthing PCMCIA related, last
> line refers to:
> 
> <6> USB Mass storage support registered.

That's correct, again you won't until auto-probe starts.

> > Can you please do not modprobe anything yourself. Your confusing me on
> > what's being autodetected and what's not.
> 
> Understood, sorry.
> 
> > Then boot IPCop again, and select auto-probe, let it do what it wants
> > and regardless of whether it found something or not, please send me
> > the output from /proc/kmsg at that point.
> > 
> 
> done, see attached logs, this is generated, following your instructions
> above, re auto-probe. Hopefully i've done this right, by running the
> following line, before I hit auto-probe, so it should have logged
> everything the auto-probe did.. I have not loaded, or typed anything
> else, other than this (to catch the output for you to look at):
> 
> cat /proc/kmsg >/harddrive/tmp/kmsg.log

O.k. That's not as useful as I though as the kmsg output is cropping
off the top. Instead of doing the 'cat' at this stage, do an 'lsmod'
and yenta_socket should be loaded.

Is it ?

Alan.

On Sat, 2004-01-31 at 22:49, Alan Hourihane wrote:
> On Sat, Jan 31, 2004 at 10:31:52PM +1030, Brendan Borlase wrote:
> > On Sat, 2004-01-31 at 21:32, Alan Hourihane wrote:
> > --snip --
> yenta_socket in 1.4a10 would only load when it's starting to auto-detect
> the network cards. It wouldn't load it at boot up. I've made a change
> in CVS which changes that, but it shouldn't make the slightest difference
> for this scenario.
> 
> So, once you've hit auto-probe then you'll see yenta_socket appear in
> the 'lsmod' output.
> 

yes, it does. I see visual output for yenta - exact output, after tty1,
and tty3 screens are loaded (same time as the first ipcop busybox screen
has loaded, prompting for language) as follows:

Install program started.
Initializing USB Controllers.
Initializing PCMCIA Controllers.
Detected PCMCIA Controller: yenta_socket


if I do a cat /proc/modules I see:

usb-storage
usbcore
sr_mod
sd_mod
scsi_mod

nothing else.

if I cat /proc/kmod, there is no mention of anthing PCMCIA related, last
line refers to:

<6> USB Mass storage support registered.

> Can you please do not modprobe anything yourself. Your confusing me on
> what's being autodetected and what's not.

Understood, sorry.

> Then boot IPCop again, and select auto-probe, let it do what it wants
> and regardless of whether it found something or not, please send me
> the output from /proc/kmsg at that point.
> 

done, see attached logs, this is generated, following your instructions
above, re auto-probe. Hopefully i've done this right, by running the
following line, before I hit auto-probe, so it should have logged
everything the auto-probe did.. I have not loaded, or typed anything
else, other than this (to catch the output for you to look at):

cat /proc/kmsg >/harddrive/tmp/kmsg.log

> Alan.
-- 
regards,

Brendan Borlase

> yanis at ihug dot com dot au

On Sat, Jan 31, 2004 at 09:33:16PM +1030, Brendan Borlase wrote:
> On Sat, 2004-01-31 at 20:55, Alan Hourihane wrote:
> > On Sat, Jan 31, 2004 at 08:46:14PM +1030, Brendan Borlase wrote:
> > > On Sat, 2004-01-31 at 20:07, Alan Hourihane wrote:
> > > > I have checked that PCMCIA works, but haven't tried a Cardbus card yet
> > > > due to lack of equipment. But I can and will today, and report back here.
> > > 
> > > Define "PCMCIA works".. neither a cardbus, nor normal PCMCIA card were
> > > detected correctly.. I don't think that exactly qualifies as working, if
> > > are going to get picky! :P
> >  
> > Maybe they weren't detected on your machine, but it is on mine. And if
> > you provide the debug output we'll be able to find out why it's not
> > on yours. I can always not bother to help either, so stop getting shitty.
> 
> Alan, I'm not getting shitty, just making a point. We're not all skilled
> programmers.. so we don't all know where to look.. I'm a System Admin by
> trade. Your tone of "voice" simply sounded tired and annoyed with yet
> annoying IPCOP user.. I apologise. 
 
Where in my 'tone of voice' did I ever sound like I was tired and annoyed ?
And you come back and start off with saying 'Define PCMCIA works' - jeesh.

> > > > Please obtain information from VT2 to say what's happening and post the
> > > > results here.
> 
> Will try to do that.. it's running now, however it's not yet being used,
> will reboot, get you the specific errors I see in VT2 (sorry, it makes
> perfect sense now.. see my comment below, re silly questions, as it
> happens I was using VT3 for the manual firing of modprobe -- chalk it up
> to a blond moment? ;-)
 
O.k.

> -- snip --
> > > 
> > > While I haven't been directly writing PCMCIA support for this, I am
> > > getting pretty familiar with _how_ ipcop handles the inital setup
> > > routine, so I can at least see what IPCOP is _trying_ to do, and
> > > sidestep it, till I can work out WHAT that particular step was that
> > > IPCOP couldn't handle..  
> > 
> > Feel free to contribute code.
> 
> Your going to start getting a moderate number of people identify stuff
> going south with PCMCIA.. I'm certain some will be fine, others won't.
 
Yes, and my replies were there to help you, and to define your problem
with debug messages.

> I'm not a programmer, I'm just a Joe Schmoe who happens to like IPCOP..
> 
> I'll endeavour to get the details on the exact SOCSxxxxx related errors
> for you. As I have suggested, the yenta_socket modprobe dosn't appear to
> have been fired correctly prior to the initial green configuration. I
> suspect that were it fine (like your laptop identifying and loading
> correctly) we'd not even be having this convo.
> 
> You'll probably end up with several "debug" snippets..
> 
> I'll try with straight auto-probe (and publish the errors) then I'll try
> firing up modprobe yenta_socket (which should make PCMCIA at least act
> like it would, were IPCOP detecting it right).. this'll give you the
> 'oops busy' debug messages I suspect..
>
> I'm very sorry about sounding shitty, but I have read more than one
> thread, where some of the IPCOP community have gone spastic at someone
> for asking, granted what appears on the surface to be a silly question,
> but to the person asking, it wasn't, yet they still get a rough deal..

To be honest, I don't think any of my comments to you sounded rough. They
are just requiring furthur information as you didn't provide enough with
your first report.

Alan.

Hello Brendan,

  as a follow up, in german support forum has a user problems to
  upload his fritzcard drivers by gui :-/

 
Kind regards

Achim Weber



-----Original Message-----
From:  Brendan Borlase <ya...@ih...>
Sent: Samstag, 31. Januar 2004, 13:10
To: Achim Weber
Subject: [IPCop-devel] 1.4.0a10 - Perl issue


> On Sat, 2004-01-31 at 22:23, Achim Weber wrote:
>>   think there is a problem with perl module Copy.pm
>> 
>>   have tested to upload a file in updates page and get error in
>>   /var/log/httpd/error_log:
>>      stat() on closed filehandle fh00001readme at
>> /usr/lib/perl5/5.8.3/File/Copy.pm line 82.
>>      -s on closed filehandle fh00001readme at
>> /usr/lib/perl5/5.8.3/File/Copy.pm line 138.
>>      sysread() on closed filehandle fh00001readme at
>> /usr/lib/perl5/5.8.3/File/Copy.pm line 146.
>> 
>>   gui errormessage:
>>      Bad file descriptor
>> 
>>   found that issue when tested addons server.

> Last time I checked, the addonz server(s) only supported 1.3, not the
> 1.4 branch (some stuff works, some dosn't).. It's more likely to be the
> addons not handling the flavour of perl in 1.4.0a10..

> I could be wrong, but remember 1.4.0a10 is an alpha release, what worked
> on .a1 may not work at all on .a10..

On Sat, 2004-01-31 at 22:43, Alan Hourihane wrote:
> On Sat, Jan 31, 2004 at 10:37:01PM +1030, Brendan Borlase wrote:
> > On Sat, 2004-01-31 at 21:37, Alan Hourihane wrote:
> > > To get debug output of whether PCMCIA is detected, switch to VT2 
> > > immediately on booting up when it asks you for the language type.
> > > 
> > > You'll notice the messages immediately. Let me know if it says
> > > Detected No PCMCIA controller.
> > 
> > Yep, finds the yenta ok.
> 
> If it found yenta o.k., you should be able to go to VT3 and type
> 'lsmod' which should list the yenta_socket module ?

The boot process does indicate yenta detected.. which you'd think should
trigger a modprobe to load the appropriate driver lol.

Yep, it should be there, and i'm buggared if I can work out why it's
not.. when going through those logs, I do see stuff about obscure issues
with picking up the PCI bus.. again, something like that could fool/
stop a modprobe going through (although it does ok manually).

> Does it not ?

Nope. Have a look at the original output.log I sent. This after initial
boot, after I did a probe (kernel output indicates yenta detected,
shortly before firing the green setup section, and everything starts to
fly past!). Prior to the first auto-probe, neither yenta_socket, nor
xircon_cb were listed.

After the first probe, xircon_cb is there, yet yenta is still nowhere to
be seen, this is effectively after a second hardware scan, the first
being boot.

It's like the hardware is detected, only either the insmod / modprobe
fails to fire, or hits an un-announced error and bails out.

Once i did a modprobe yenta_socket, in the kmsg_with_yenta.log you can
see it identifies the slots (due to yenta_socket being loaded) only the
drivers don't load for anything else..

I noticed that xirc2ps_cs is not auto-probed.. even tho it is an
included module.. this could be contributing to ipcop not "seeing" the
cards, the module's not run..

once I fire a modprobe xirc2ps_cs, modprobe pcnet_cs, and then run
auto-probe again, it hell breaks loose and the cards found. 

Weird eh?

-- 
regards,

Brendan Borlase

> yanis at ihug dot com dot au

>>   think there is a problem with perl module Copy.pm
>> 
>>   have tested to upload a file in updates page and get error in
>>   /var/log/httpd/error_log:
>>      stat() on closed filehandle fh00001readme at
>> /usr/lib/perl5/5.8.3/File/Copy.pm line 82.
>>      -s on closed filehandle fh00001readme at
>> /usr/lib/perl5/5.8.3/File/Copy.pm line 138.
>>      sysread() on closed filehandle fh00001readme at
>> /usr/lib/perl5/5.8.3/File/Copy.pm line 146.
>> 
>>   gui errormessage:
>>      Bad file descriptor
>> 
>>   found that issue when tested addons server.

> Last time I checked, the addonz server(s) only supported 1.3, not the
> 1.4 branch (some stuff works, some dosn't).. It's more likely to be the
> addons not handling the flavour of perl in 1.4.0a10..

> I could be wrong, but remember 1.4.0a10 is an alpha release, what worked
> on .a1 may not work at all on .a10..

no, this has nothing to do with addons server.

you can simply reproduce it by uploading a file in ipcop-updates page.
you will get errors above.

have rechecked with .a5, when i upload same file (in updates page) i
get gui error: 
  This is not an authorised update, or your patchlist is out of date.
as it should be!

Achim

On Sat, Jan 31, 2004 at 10:31:52PM +1030, Brendan Borlase wrote:
> On Sat, 2004-01-31 at 21:32, Alan Hourihane wrote:
> --snip --
> > It's also worth switching to VT3 (press ALT+F3) and then do
> > 
> > cat /proc/kmsg
> > 
> > to look at what the kernel is doing.
> --snip--
> 
> System: 	IBM 760XL
> Proc:		Pentium 166
> Mem:		86
> 
> Okay, when I /cat/kmsg while running modprobe, it rolls through all the
> pcmcia drivers and seems to skip 'em all, although it gets a strike on
> xircom_cb.
> 
> Any debug info I can get to write to the hdd's /tmp directory I'll
> attach at end of email to give you something to go through..
> 
> Dumped /proc/modules & /proc/kmsg to files ok..
> 
> I'm going to try to modprobe yenta_socket (to reflect what should have
> happened at boot time) to see if that allows the auto-probe to work.

yenta_socket in 1.4a10 would only load when it's starting to auto-detect
the network cards. It wouldn't load it at boot up. I've made a change
in CVS which changes that, but it shouldn't make the slightest difference
for this scenario.

So, once you've hit auto-probe then you'll see yenta_socket appear in
the 'lsmod' output.

Can you please do not modprobe anything yourself. Your confusing me on
what's being autodetected and what's not.

Then boot IPCop again, and select auto-probe, let it do what it wants
and regardless of whether it found something or not, please send me
the output from /proc/kmsg at that point.

Alan.

On Sat, 2004-01-31 at 21:32, Alan Hourihane wrote:

--snip --
> It's also worth switching to VT3 (press ALT+F3) and then do
> 
> cat /proc/kmsg
> 
> to look at what the kernel is doing.
--snip--

System: 	IBM 760XL
Proc:		Pentium 166
Mem:		86

Okay, when I /cat/kmsg while running modprobe, it rolls through all the
pcmcia drivers and seems to skip 'em all, although it gets a strike on
xircom_cb.

Any debug info I can get to write to the hdd's /tmp directory I'll
attach at end of email to give you something to go through..

Dumped /proc/modules & /proc/kmsg to files ok..

I'm going to try to modprobe yenta_socket (to reflect what should have
happened at boot time) to see if that allows the auto-probe to work.

Ok, still no joy. Erm, I just finished loading everything for pcmcia
short of psnet_cs, and it's just done an autoprobe fine!

Weird!

I know that my laptop dosn't support cardbus too well, it works fine
with cardbus, just not all O/S's support it.

I'll attach the output logs I managed to get for review..

Sorry I can't be any more helpfull! Though, unless the log files point
to something else, the PCMCIA sockets being identified, just not insmod
/ modprobe'd initially is going to make the rest fail.

Soon as the yenta_socket is loaded, and pcmcia_core load, it seems to be
able to make sense of what's plugged in...

-- 
regards,

Brendan Borlase

> yanis at ihug dot com dot au

On Sat, Jan 31, 2004 at 10:37:01PM +1030, Brendan Borlase wrote:
> On Sat, 2004-01-31 at 21:37, Alan Hourihane wrote:
> > To get debug output of whether PCMCIA is detected, switch to VT2 
> > immediately on booting up when it asks you for the language type.
> > 
> > You'll notice the messages immediately. Let me know if it says
> > Detected No PCMCIA controller.
> 
> Yep, finds the yenta ok.

If it found yenta o.k., you should be able to go to VT3 and type
'lsmod' which should list the yenta_socket module ?

Does it not ?

Alan.

  think there is a problem with perl module Copy.pm

  have tested to upload a file in updates page and get error in
  /var/log/httpd/error_log:
     stat() on closed filehandle fh00001readme at /usr/lib/perl5/5.8.3/File/Copy.pm line 82.
     -s on closed filehandle fh00001readme at /usr/lib/perl5/5.8.3/File/Copy.pm line 138.
     sysread() on closed filehandle fh00001readme at /usr/lib/perl5/5.8.3/File/Copy.pm line 146.

  gui errormessage:
     Bad file descriptor

  found that issue when tested addons server.


Kind regards

Achim Weber

On Sat, 2004-01-31 at 20:55, Alan Hourihane wrote:
> On Sat, Jan 31, 2004 at 08:46:14PM +1030, Brendan Borlase wrote:
> > On Sat, 2004-01-31 at 20:07, Alan Hourihane wrote:
> > > On Sat, Jan 31, 2004 at 07:22:28PM +1030, Brendan Borlase wrote:
> > > > On Sat, 2004-01-31 at 19:05, Brendan Borlase wrote:
> > > > > PCMCIA is borked as well.. try as I might, i can't work out the right
> > > > > steps to get a pcmcia card working..
> > > > 
> > > > hah! I have it - load master Alan H's dummy driver, AFTER fireing up
> > > > modprobe in a second session with required drivers...
> > > 
> > > No, you shouldn't have to load the dummy driver.
> > 
> > Yes, I know that.. I _should_ be able to autoprobe & have IPCOP do all
> > the work and load everything. Failing that, I _should_ be able to
> > manually choose the PCMCIA card, and everything will work fine.. It's
> > not, and this is the first release with PCMCIA more or less complete.. I
> > don't expect it to work out of the box..
>  
> It does work out of the box as I've tried it with some PCMCIA cards.
> You can't manually choose a PCMCIA card either, it will auto-load it 
> regardless. Only Cardbus is allowable to manually select.
> 

Indeed.

> > > I have checked that PCMCIA works, but haven't tried a Cardbus card yet
> > > due to lack of equipment. But I can and will today, and report back here.
> > 
> > Define "PCMCIA works".. neither a cardbus, nor normal PCMCIA card were
> > detected correctly.. I don't think that exactly qualifies as working, if
> > are going to get picky! :P
>  
> Maybe they weren't detected on your machine, but it is on mine. And if
> you provide the debug output we'll be able to find out why it's not
> on yours. I can always not bother to help either, so stop getting shitty.

Alan, I'm not getting shitty, just making a point. We're not all skilled
programmers.. so we don't all know where to look.. I'm a System Admin by
trade. Your tone of "voice" simply sounded tired and annoyed with yet
annoying IPCOP user.. I apologise. 

> > > Please obtain information from VT2 to say what's happening and post the
> > > results here.

Will try to do that.. it's running now, however it's not yet being used,
will reboot, get you the specific errors I see in VT2 (sorry, it makes
perfect sense now.. see my comment below, re silly questions, as it
happens I was using VT3 for the manual firing of modprobe -- chalk it up
to a blond moment? ;-)

-- snip --
> > 
> > While I haven't been directly writing PCMCIA support for this, I am
> > getting pretty familiar with _how_ ipcop handles the inital setup
> > routine, so I can at least see what IPCOP is _trying_ to do, and
> > sidestep it, till I can work out WHAT that particular step was that
> > IPCOP couldn't handle..  
> 
> Feel free to contribute code.

Your going to start getting a moderate number of people identify stuff
going south with PCMCIA.. I'm certain some will be fine, others won't.

I'm not a programmer, I'm just a Joe Schmoe who happens to like IPCOP..

I'll endeavour to get the details on the exact SOCSxxxxx related errors
for you. As I have suggested, the yenta_socket modprobe dosn't appear to
have been fired correctly prior to the initial green configuration. I
suspect that were it fine (like your laptop identifying and loading
correctly) we'd not even be having this convo.

You'll probably end up with several "debug" snippets..

I'll try with straight auto-probe (and publish the errors) then I'll try
firing up modprobe yenta_socket (which should make PCMCIA at least act
like it would, were IPCOP detecting it right).. this'll give you the
'oops busy' debug messages I suspect..

I'm very sorry about sounding shitty, but I have read more than one
thread, where some of the IPCOP community have gone spastic at someone
for asking, granted what appears on the surface to be a silly question,
but to the person asking, it wasn't, yet they still get a rough deal..

-- 
regards,

Brendan Borlase

> yanis at ihug dot com dot au

On Sat, Jan 31, 2004 at 09:38:01PM +1030, Brendan Borlase wrote:
> On Sat, 2004-01-31 at 21:32, Alan Hourihane wrote:
> > On Sat, Jan 31, 2004 at 09:37:37AM +0000, Alan Hourihane wrote:
> > > I have checked that PCMCIA works, but haven't tried a Cardbus card yet
> > > due to lack of equipment. But I can and will today, and report back here.
> > 
> > Just tried cardbus here and it works too, by either probing or manual
> > selection.
> 
> Excellent! Lucky bugger, just trying a re-install now :D

I tried a Tulip based cardbus card.

> > I also plugged in my REM56G Xircom card and that works too via probing.
> 
> REM56G ?? ahh, yup, that's just a standard (ie non-cardbus) card yeah?
 
Yes.

> > It's also worth switching to VT3 (press ALT+F3) and then do
> > 
> > cat /proc/kmsg
> 
> :-) Thanks Alan! expect a heap-o-output shortly..

Bring it on.

Alan.

To get debug output of whether PCMCIA is detected, switch to VT2 
immediately on booting up when it asks you for the language type.

You'll notice the messages immediately. Let me know if it says
Detected No PCMCIA controller.

If it does, can you switch to VT3 and do a 'cat /proc/pci' and send
me that info.

Alan.

Version: IPCop 1.4.0a10 (downloaded from Sourceforge area as ISO)
Machine : i586 GenuineIntel
Memory : 32Mb
Test Area : VPN (Roadwarrior) & VPN (Net to Net)


I concur with Jurgen Johannsen, in that you cannot add two VPN connections.=
 As you configure the second VPN, it appears to replace the existing one. It=
 does not just appear to be a GUI issue, as I tried connecting using the=
 missing VPN option.


Otherwise I have run a few individual tests on the VPN area of 1.4.0a10. The=
 findings and setups are as follows

VPN Roadwarrior
--------------------

External System : Laptop using XP and SSH Sentinel. Dialup link with dynamic=
 address
Internal System : IPCOP with Static IP address, configured for Road Warrior=
 VPN.
Tested : Successful and stable over multiple reconnections.

VPN Net to Net
------------------

External System : Dlink 804 ADSL Router/Modem with with static address
Internal System : IPCOP with Static IP address, configured for Net to Net=
 VPN.
Tested : Successful and stable over multiple reconnections.


The VPN's were easy to setup, the logs generally provided any VPN=
 negotiation issues, and after setting up both VPN's the language/layout=
 appears to be appropriate in terms of relating to other VPN documentation=
 (e.g. the use of word roadwarrior etc).

Regards

Bob Fryer

On Sat, Jan 31, 2004 at 08:46:14PM +1030, Brendan Borlase wrote:
> On Sat, 2004-01-31 at 20:07, Alan Hourihane wrote:
> > On Sat, Jan 31, 2004 at 07:22:28PM +1030, Brendan Borlase wrote:
> > > On Sat, 2004-01-31 at 19:05, Brendan Borlase wrote:
> > > > PCMCIA is borked as well.. try as I might, i can't work out the right
> > > > steps to get a pcmcia card working..
> > > 
> > > hah! I have it - load master Alan H's dummy driver, AFTER fireing up
> > > modprobe in a second session with required drivers...
> > 
> > No, you shouldn't have to load the dummy driver.
> 
> Yes, I know that.. I _should_ be able to autoprobe & have IPCOP do all
> the work and load everything. Failing that, I _should_ be able to
> manually choose the PCMCIA card, and everything will work fine.. It's
> not, and this is the first release with PCMCIA more or less complete.. I
> don't expect it to work out of the box..
 
It does work out of the box as I've tried it with some PCMCIA cards.
You can't manually choose a PCMCIA card either, it will auto-load it 
regardless. Only Cardbus is allowable to manually select.

> > I have checked that PCMCIA works, but haven't tried a Cardbus card yet
> > due to lack of equipment. But I can and will today, and report back here.
> 
> Define "PCMCIA works".. neither a cardbus, nor normal PCMCIA card were
> detected correctly.. I don't think that exactly qualifies as working, if
> are going to get picky! :P
 
Maybe they weren't detected on your machine, but it is on mine. And if
you provide the debug output we'll be able to find out why it's not
on yours. I can always not bother to help either, so stop getting shitty.

> > Please obtain information from VT2 to say what's happening and post the
> > results here.
> 
> When i work out VT2 is, I'll do that.. As stated I had to sidestep auto
> probe (yeah, like it's going to work flawlessly, on all PCMCIA
> supporting laptops, with most xircom cards, first time round!) manual
> loading didn't work, all due to modprobe identifying a yenta_socket, but
> not actually doing anything with it, (you can fire another modprobe
> yenta_socket without an error, third time, it correctly indicates the
> module is loaded).
> 
> The problem with PCMCIA is you have a crap load going on at once,
> multiple module dependency's cascading on top of each other..
> 
> In my case, first we can modprobe pcmcia_core, then modprobe
> yenta_socket (which triggers at least 1 dependency driver) then modprobe
> the card itself, in my case it was modprobe xircom_cb, which of course
> triggers i think 3-4 module dependency's as well (which load ok).
> 
> At this point the only thing left is the serial_cs if needed, then
> lastly we can modprobe pcnet_cs to fire up network services.
> 
> I could not get the network to start correctly AT ANY STAGE during this
> process.. and I started from scratch, and added an additional layer of
> PCMCIA support each reboot. Each time IPCOP either could not "see" eth0,
> or _could_ see it, however the device was "busy".. it shouldn't be busy
> as it's theoretically only just been assigned an address to use, it
> hasn't be brought UP yet! (although PCMCIA cards are "active" once
> loaded by default, perhaps this is the cause of IPCOP's confusion).
> 
> All that firing the DUMMY driver does, is cause ipcop to pull the
> network up routine on a sane PCMCIA config.. It dosn't, pardon my
> french, fuck with PCMCIA, it just identifies the card(s) existance, that
> PCMCIA is sane and bounces PCMCIA to bring the card up.. otherwise we
> end up with either to many, or two few drivers loaded for IPCOP to
> manage bringing the network UP.
> 
> While I haven't been directly writing PCMCIA support for this, I am
> getting pretty familiar with _how_ ipcop handles the inital setup
> routine, so I can at least see what IPCOP is _trying_ to do, and
> sidestep it, till I can work out WHAT that particular step was that
> IPCOP couldn't handle..  

Feel free to contribute code.

Alan.

On Sat, Jan 31, 2004 at 08:20:08PM +1030, Brendan Borlase wrote:
> On Sat, 2004-01-31 at 20:05, Alan Hourihane wrote:
> -- snip --
> > On Sat, Jan 31, 2004 at 07:05:32PM +1030, Brendan Borlase wrote:
> > > PCMCIA is borked as well.. try as I might, i can't work out the right
> > > steps to get a pcmcia card working..
> 
> > I would certainly try your other card too, but we need some kind of
> > output that your getting from VT2 Brendan, without that we're blowing
> > in the wind.
> > 
> -- snip --
> 
> pardon my stupidity, but what exactly is VT2?

Press ALT+F2 to switch to the second VT, and there's some debug output.

Alan.

On Sat, 2004-01-31 at 20:07, Alan Hourihane wrote:
> On Sat, Jan 31, 2004 at 07:22:28PM +1030, Brendan Borlase wrote:
> > On Sat, 2004-01-31 at 19:05, Brendan Borlase wrote:
> > > PCMCIA is borked as well.. try as I might, i can't work out the right
> > > steps to get a pcmcia card working..
> > 
> > hah! I have it - load master Alan H's dummy driver, AFTER fireing up
> > modprobe in a second session with required drivers...
> 
> No, you shouldn't have to load the dummy driver.

Yes, I know that.. I _should_ be able to autoprobe & have IPCOP do all
the work and load everything. Failing that, I _should_ be able to
manually choose the PCMCIA card, and everything will work fine.. It's
not, and this is the first release with PCMCIA more or less complete.. I
don't expect it to work out of the box..

> 
> I have checked that PCMCIA works, but haven't tried a Cardbus card yet
> due to lack of equipment. But I can and will today, and report back here.
> 

Define "PCMCIA works".. neither a cardbus, nor normal PCMCIA card were
detected correctly.. I don't think that exactly qualifies as working, if
are going to get picky! :P

I currently have a "sane" install of IPCOP, including two pcmcia
adapters (i want to start working with an orange interface).. this
proves the pcmcia environment is sane enough to up/down, and at this
stage I don't see any bad packets on either interface..


> Please obtain information from VT2 to say what's happening and post the
> results here.

When i work out VT2 is, I'll do that.. As stated I had to sidestep auto
probe (yeah, like it's going to work flawlessly, on all PCMCIA
supporting laptops, with most xircom cards, first time round!) manual
loading didn't work, all due to modprobe identifying a yenta_socket, but
not actually doing anything with it, (you can fire another modprobe
yenta_socket without an error, third time, it correctly indicates the
module is loaded).

The problem with PCMCIA is you have a crap load going on at once,
multiple module dependency's cascading on top of each other..

In my case, first we can modprobe pcmcia_core, then modprobe
yenta_socket (which triggers at least 1 dependency driver) then modprobe
the card itself, in my case it was modprobe xircom_cb, which of course
triggers i think 3-4 module dependency's as well (which load ok).

At this point the only thing left is the serial_cs if needed, then
lastly we can modprobe pcnet_cs to fire up network services.

I could not get the network to start correctly AT ANY STAGE during this
process.. and I started from scratch, and added an additional layer of
PCMCIA support each reboot. Each time IPCOP either could not "see" eth0,
or _could_ see it, however the device was "busy".. it shouldn't be busy
as it's theoretically only just been assigned an address to use, it
hasn't be brought UP yet! (although PCMCIA cards are "active" once
loaded by default, perhaps this is the cause of IPCOP's confusion).

All that firing the DUMMY driver does, is cause ipcop to pull the
network up routine on a sane PCMCIA config.. It dosn't, pardon my
french, fuck with PCMCIA, it just identifies the card(s) existance, that
PCMCIA is sane and bounces PCMCIA to bring the card up.. otherwise we
end up with either to many, or two few drivers loaded for IPCOP to
manage bringing the network UP.

While I haven't been directly writing PCMCIA support for this, I am
getting pretty familiar with _how_ ipcop handles the inital setup
routine, so I can at least see what IPCOP is _trying_ to do, and
sidestep it, till I can work out WHAT that particular step was that
IPCOP couldn't handle..  

-- 
regards,

Brendan Borlase

> yanis at ihug dot com dot au

On Sat, 2004-01-31 at 20:05, Alan Hourihane wrote:
-- snip --
> On Sat, Jan 31, 2004 at 07:05:32PM +1030, Brendan Borlase wrote:
> > PCMCIA is borked as well.. try as I might, i can't work out the right
> > steps to get a pcmcia card working..

> I would certainly try your other card too, but we need some kind of
> output that your getting from VT2 Brendan, without that we're blowing
> in the wind.
> 
-- snip --

pardon my stupidity, but what exactly is VT2?

-- 
regards,

Brendan Borlase

> yanis at ihug dot com dot au