AW: [leaf-user] Aliasing IP Addres : HOWTO do ?
> I don't understand how to have a second IP address on the same > interface. > I have hear some sound about aliasing... > I have searched but not trieve exactly hot to do, and a real example. > > If somebody knows... > > I have already 192.168.73.254/24 on this NIC, but I want also > 44.151.100.254/24. Additional to what the others said, this is how you can config it automatically by editing the /etc/network/interfaces file: auto eth0 iface eth0 inet static address 192.168.73.254 masklen 24 up ip addr add 44.151.100.254/24 dev eth0 label eth0:public You can the address the 192. address with eth0 and the 44. address with eth0:public. The label is optional but sometimes handy Regards Alex --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] My Dachstein not quite up and running
Apologies for the typo in my previous messages. My two problems haven't
gone away--1) Exchange server is not receiving internet email and 2)
workstations cannot browse the web. I'm thinking my first problem is
related to Doug's problem under the recent headers: Dachstein Port
Forwarding, but since I'm not a trained Exchange Sysadmin like he is I'm in
need of more specific how-to help. Here's the current setup:
T-1 line in
|
|
ISP's router (external IP: 208.57.96.254; internal IP: 192.168.1.1)
|
|
Firewall (external IP: 192.168.1.2; internal IP: 10.10.10.254)
|
|
Exchange Server (IP: 10.10.10.200, Gateway: 10.10.10.254)
The portfw module is loaded.
I made the following changes to network.conf:
# TCP services open to outside world
# Space seperated list: srcip/mask_dstport
#EXTERN_TCP_PORTS="216.171.153.128/25_ssh 0/0_www 0/0_1023"
EXTERN_TCP_PORTS="192.168.1.2_25"
and
# Uncomment following for port-forwarded internal services.
# The following is an example of what should be put here.
# Tuples are as follows:
#
#INTERN_SERVERS="tcp_${EXTERN_IP}_ftp_192.168.1.1_ftp
tcp_${EXTERN_IP}_smtp_192.168.1.1_smtp"
INTERN_SERVERS="tcp_$192.168.1.2_smtp_10.10.10.200_smtp"
and
CONFIG_DNS=YES
and
DOMAINS="private.network"
#DNS0=127.0.0.1
DNS0=208.57.0.10
DNS1=208.57.0.11
Output of netstat -nr:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.1.1 0.0.0.0 UG0 0 0 eth0
Output of ipchains -nvL:
Chain input (policy DENY: 0 packets, 0 bytes):
pkts bytes target prot opttosa
tosx ifname mark outsize sourcedestination
ports
31 2232 DENY udp -- 0xFF
0x00 eth0 192.168.1.1 0.0.0.0/0
* -> 520
0 0 DENY udp -- 0xFF
0x00 eth0 0.0.0.0 0.0.0.0/0
* -> 68
0 0 DENY icmp l- 0xFF
0x00 * 0.0.0.0/00.0.0.0/0
5 -> *
0 0 DENY icmp l- 0xFF
0x00 * 0.0.0.0/00.0.0.0/0
13 -> *
0 0 DENY icmp l- 0xFF
0x00 * 0.0.0.0/00.0.0.0/0
14 -> *
0 0 DENY all l- 0xFF
0x00 eth0 0.0.0.0 0.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 255.255.255.255 0.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 127.0.0.0/8 0.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 224.0.0.0/4 0.0.0.0/0
n/a
0 0 DENY all -- 0xFF
0x00 eth0 10.0.0.0/8 0.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 172.16.0.0/120.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 0.0.0.0/80.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 128.0.0.0/16 0.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 191.255.0.0/16 0.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 192.0.0.0/24 0.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 223.255.255.0/24 0.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 240.0.0.0/4 0.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 10.10.10.0/240.0.0.0/0
n/a
0 0 DENY all l- 0xFF
0x00 eth0 192.168.1.2 0.0.0.0/0
n/a
0 0 REJECT all l- 0xFF
0x00 eth0 0.0.0.0/0127.0.0.0/8
n/a
0 0 REJECT all l- 0xFF
0x00 eth0 0.0.0.0/010.10.10.0/24
n/a
0 0 REJECT tcp -- 0xFF
0x00 eth0 0.0.0.0/00.0.0.0/0
* -> 137
0 0 REJECT tcp -- 0xFF
0x00 eth0 0.0.0.0/00.0.0.0/0
* -> 135
15 1170 REJECT udp -- 0xFF
0x00 eth0 0.0.0.0/00.0.0.0/0
* -> 137
0 0 REJECT udp -- 0xFF
0x00 eth0 0.0.0.0/00.0.0.0/0
* -> 135
0 0 REJECT tcp -- 0xFF
0x00 eth0 0.0.0.
Re: [leaf-user] It Works!!
On Tue, 11 Feb 2003, Lynn Avants wrote: > On Tuesday 11 February 2003 09:28 pm, David Pitts wrote: > > That was the odd thing. No error messages that I could see, it just > > didn't work on boot, although it was fine from the command line. > > OK, come to think about it there is another possible init problem that > I haven't considered. If two or more init scripts share the same > rc# only one of the scripts (or none) are run. If there is a conflict > with another script on the system, the udhcpd script may not be > run at all on boot. My understanding it is that the RCDLINKS data are converted to symbolic links in the various runlevel directories, and then the scripts are executed in alphabetical order. Thus, where the rc#'s are the same, the scripts are run in alphabetical order as a fallback... which may or may not meet your sequencing requirements, but should never result in a script not being run. > I ran into this when I packaged lcd.lrp, so I'll do > some checking and see if I can resolve the issue. Thanks for your > patience. --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] problems with BEFW11S (wireless router) and LEAF (Bering)
Ok, what are the ip address(es) of your wireless machine(s) clients, not Linksys. Also, what do the wireless clients have for default gateway and dns servers? The ip address of the wireless machine is 192.168.1.3 and have 192.168.1.254 (Bering IP address) as the default gateway and dns. Another long shot ... is the routing table on the XP host correctly configured after it gets its DHCP lease? What do you mean? The wireless host does have all the proper addresses (IP, gateway, DNS) so I don't think the DHCP has any problems. And this SAME wireline host can also ping the same wireless host that the Bering router cannot find? (A prior message said a wireline host can ping a wireless host and vice versa; i'm only double checking that those hosts are the same ones you are talking about here.) Yes the wireline can ping the wireless and vice versa. CK --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] It Works!!
On Tuesday 11 February 2003 09:28 pm, David Pitts wrote: > That was the odd thing. No error messages that I could see, it just > didn't work on boot, although it was fine from the command line. OK, come to think about it there is another possible init problem that I haven't considered. If two or more init scripts share the same rc# only one of the scripts (or none) are run. If there is a conflict with another script on the system, the udhcpd script may not be run at all on boot. I ran into this when I packaged lcd.lrp, so I'll do some checking and see if I can resolve the issue. Thanks for your patience. > I don't actually find any of this frustrating. I only do it for fun and > learning and I find it very good for both! I agree. ;-) -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] RE: Bering1.0-stable Problem with 2.4.20 onnet4501 (Steve Bihari)
> Well who would of thunk ?! > > Downgrading to 2.4.18-14 (stock RHAT 8.0 kernel) fixed it. > > I feel so much better. Man, are you sure you are using modules that _perfectly_ match the kernel you are booting? I am quite sure there is something about the natsemi driver in particular that makes it intolerant to being used on different kernels. Maybe search back through the archives of this list. I am fairly certain that this subject is the first one I posted to this list when I got my soekris. -- --- Chad Carr [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
At 07:14 PM 2/11/03 -0800, Tom Eastep wrote: Lynn Avants wrote: That used to be somewhat true until stateful firewalls started being used. Before that there would have been so many problems with net-based applications while filtering high-ports that most firewall's never gave much thought to blocking this traffic under SOHO use. There is something that we are missing here regarding the difference between his Dachstein and Bering configurations. Not only would these high ports have to have been open but they would have to have been forwarded to the internal machine running his P2P application. That would have required an explicit configuration action on his part. I *think* this assertion is incorrect. The firewall paper Sean referred us to *seems* to be describing a workaround for exactly this requirement. I don't fully understand how they do it (either the paper intentionally omits some key technical detail, or I just missed it). Lynn's suggestion above, a more succinct expression of the thought I talked about in rambly form, is probably closer to the target. The exception would be if the application is built on some standard technology like IRC where a masquerade module is available on Dachstein but not on Bering. -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] It Works!!
That was the odd thing. No error messages that I could see, it just didn't work on boot, although it was fine from the command line. I don't actually find any of this frustrating. I only do it for fun and learning and I find it very good for both! Thanks again. David Pitts IT Services Manager Reid Library University of Western Australia Telephone: (08) 9380 3492 Fax: (08) 9380 1012 -Original Message- From: Lynn Avants [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 12 February 2003 10:49 AM To: [EMAIL PROTECTED] Subject: Re: [leaf-user] It Works!! On Tuesday 11 February 2003 08:12 pm, David Pitts wrote: > I have got it going! A three interface Bering. And I guess it should > have been easier than I made it seem but thanks a lot for your help. > > Lynn, I gave up on uDHCP and reinstalled the default Pump and DHCP and > everything works fine. Great! I'm glad your up and running. Concerning the init order between udhcpc and shorewall: >From /etc/init.d/shorewall RCDLINKS="2,S41 3,S41 6,K41" >From /etc/init.d/udhcpc RCDLINKS="S,S38 6,K38" Ok, from this udhcpc runs before shorewall in init (38,41). unless you are having an error message of some type that I don't remember. I'll see if I can replicate the error sometime in the next week. The only possibility I see is adding 'svi shorewall restart' in the /etc/udhcpc.hooks file when a lease is changed after boot. > For my next project I will make a bootable CD version and set up SSH > on that. So we will meet again. Hopefully it will be less frustrating next time. ;-) -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall vs. Dachstein
At 08:53 PM 2/11/03 -0500, Sean wrote: Thanks for your responses. After spending more time on their website, I discovered their "Any-Firewall-Whitepaper" where it states that I actually don't have a problem since their technology works transparent to firewalls and NAT. Lynn, you are correct. There are some high UDP ports, but according to their white-paper, these are only "outgoing" connections. Since it's a peer-to-peer connection, I'm not sure how both parties can have outgoing connections, and no incoming connections...but its obviously some highly advanced technology! What's my exposure when opening those TCP and UDP ports? I'm VERY new to iptables, so be gentle. I've been watching this one from the sidelines, mostly because the information I found at EyeBallChat site was mostly bafflegab (except for the static ports stuff Lynn had already directed you to). I don't know this service ... but usually with p2p, *somebody* needs to be able to accept connections. Either half of each pair needs this ability (I believe Direct Connect, for example, works this way), or the system relays through a central site to bypass firewalling problems (I believe GoToMyPC, for example, works this way) ... making it not really p2p, of course. From reading the Firewalling White Paper you alluded to, it becomes clear that EyeBallChat adopts a mixed approach,one somewhat similar to the "hub" portion of popular p2p packages but a bit more capable in that it can handle identifying the IP address and source port on the fly. This is actually a neat workaround. (Anyone curious can find the White Paper at http://www.eyeball.com/solutions/Any-FirewallWhitePaper.pdf -- it is actually interesting.) Reading this paper suggests to me that you shouldn't actually need to adopt the static-port solution ... fortunately, since they don't define "open up" and I'm having trouble guessing what they mean by the term (probably "port forward", but I'm way far from sure). The While Paper claims their standard approach works with both ipchains and iptables, and since it did work for you with Dachstein (=ipchains), I'm inclined to believe them, at least provisionally. So, I suggest you tell us a bit more, namely: 1. What were the "high UDP" ports used by Dachstein? I'm guessing they were in the range (roughly 6-65000) Linux kernels use for outgoing NAT'd connections. And were there *really* only UDP ports ... no TCP? 2. On Bering, what does your firewall ruleset look like? We just care about the forwarding parts, but this is divided between two tables, so we need to see iptables -t nat -nvL iptables -t filter -nvL or the built-in Shorewall equivalents (which I continue to forget, no matter how many times Mike reminds me). Run these commands *after* an unsuccessful attempt with EyeBallChat, so we can look for rules that blocked a bunch of packets. It is now sounding to me like Shorewall (or conceivably some other kernel setting) is doing something specific to block you, and we need more than the blather that EyeBallChat provides to figure out what. 3. Do you still have the Dachstein firewall running anywhere? If so, it would be instructive to see its rulesets too: ipchains -nvL I suppose it is possible that the EyeBallChat solution sorts out the address/port stuff right, but leaves both ends with the impression that they are initiating the connection. This could cause incoming TCP packets (if it uses TCP, as the static solution appears to) to have the wrong flags set, and so be blocked by Shorewall seeing them as NEW rather than ESTABLISHED (the Dach firewall may not have checked for this). It is unclear to me if there might be a similar problem with UDP ... UDP itself has no concept of a connection, but the iptables documentation is a bit inexact about how an iptables kernel decides if a UDP packet is NEW, ESTABLISHED, or one of the other states (and I don't really recall if ipchains even has these concepts for UDP traffic). If it is the problem, it would be worth calling it to their attenton, since it represents a weakness in their trademarked solution that they will want to fix (or at least, I hope, feel obliged to disclose). This part is just speculation, though. If you do end up using the static-port solution, and if "open up" really means "port forward" ... then the risk you run is that the EyeBallChat software itself has a security hole. It is the same risk you run every time you port forward to a server running a service, or a p2p app that uses fixed ports, on your LAN or DMZ. This is not really a LEAF, or even a Linux, question ... I suggest you turn to third-party EyeBallChat commentary to assess this. -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- -
Re: [leaf-user] Bering/Shorewall vs. Dachstein
Lynn Avants wrote: That used to be somewhat true until stateful firewalls started being used. Before that there would have been so many problems with net-based applications while filtering high-ports that most firewall's never gave much thought to blocking this traffic under SOHO use. There is something that we are missing here regarding the difference between his Dachstein and Bering configurations. Not only would these high ports have to have been open but they would have to have been forwarded to the internal machine running his P2P application. That would have required an explicit configuration action on his part. The exception would be if the application is built on some standard technology like IRC where a masquerade module is available on Dachstein but not on Bering. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall vs. Dachstein
On Tuesday 11 February 2003 07:53 pm, Sean wrote: > Thanks for your responses. > > After spending more time on their website, I discovered their > "Any-Firewall-Whitepaper" where it states that I actually don't have a > problem since their technology works transparent to firewalls and > NAT. That used to be somewhat true until stateful firewalls started being used. Before that there would have been so many problems with net-based applications while filtering high-ports that most firewall's never gave much thought to blocking this traffic under SOHO use. > Lynn, you are correct. There are some high UDP ports, but according to > their white-paper, these are only "outgoing" connections. Since it's a > peer-to-peer connection, I'm not sure how both parties can have outgoing > connections, and no incoming connections...but its obviously some highly > advanced technology! What's my exposure when opening those TCP and UDP > ports? I'm VERY new to iptables, so be gentle. Really the largest security risk in doing this is highly dependant on the application listening on these ports. You'll probably need to portfw the TCP ports at a minimum for the remote side to initiate a connection, but I may be wrong in this assumption w/o trying the application first. -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] It Works!!
On Tuesday 11 February 2003 08:12 pm, David Pitts wrote: > I have got it going! A three interface Bering. And I guess it should > have been easier than I made it seem but thanks a lot for your help. > > Lynn, I gave up on uDHCP and reinstalled the default Pump and DHCP and > everything works fine. Great! I'm glad your up and running. Concerning the init order between udhcpc and shorewall: >From /etc/init.d/shorewall RCDLINKS="2,S41 3,S41 6,K41" >From /etc/init.d/udhcpc RCDLINKS="S,S38 6,K38" Ok, from this udhcpc runs before shorewall in init (38,41). unless you are having an error message of some type that I don't remember. I'll see if I can replicate the error sometime in the next week. The only possibility I see is adding 'svi shorewall restart' in the /etc/udhcpc.hooks file when a lease is changed after boot. > For my next project I will make a bootable CD version and set up SSH on > that. So we will meet again. Hopefully it will be less frustrating next time. ;-) -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering1.0-stable Problem with 2.4.20 onnet4501
Well who would of thunk ?! Downgrading to 2.4.18-14 (stock RHAT 8.0 kernel) fixed it. I feel so much better. Thanks All ! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Steve Bihari Sent: Monday, February 10, 2003 8:33 PM To: 'Michael Bonner'; [EMAIL PROTECTED] Subject: RE: [leaf-user] Bering1.0-stable Problem with 2.4.20 onnet4501 All, Some more info on this... I recompiled the kernel for natsemi Module support instead of native kernel support for the dp83815. The module loads fine on bootup and detects all three integrated interfaces. But as soon as the load progresses to "Configuring Network Interface..", sure enough, same think. Crash !!! ...Steve >>> "Steve Bihari" <[EMAIL PROTECTED]> 02/09/03 15:11 PM >>> Hi all, I'm getting the following kernel panic on my bering1.0_stable box with kernel 2.4.20 This is running on a Soekris net4501 . Anyone else see this? Unable to handle kernel NULL pointer dereference at virtual addr ess printing eip: *pde = Oops: CPU:0 EIP:0010:[<>]Not tainted EFLAGS: 00010286 eax: c10d3da0 ebx: c3c1f2b0 ecx: c4815860 edx: 0025 esi: c0241f08 edi: 0002 ebp: c3dde81e esp: c0241e70 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0241000) Stack: c01e8caf c3dde81e 0025 c3c1f2b0 0002 0002 c0241ee8 c01bcf70 c0279d80 c01afef6 c0241f08 c10db800 c01bcf70 c01bcf70 c01b01a3 c0279d80 c0241f08 Call Trace:[] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: Bad EIP value. <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] upgrading to stable bearing release
Jim Van Eeckhoutte wrote: Hey guys ... been running Bearing Kernel:Linux version 2.4.18 (bering5@debian) (gcc version 2.95.2 and ... i know i know (not supposed tooo) installed to hard drive because of packages. What do i need to do to upgrade to the stable release of bearing? Also running Shorewall 1.2.8. Jim, For Shorewall upgrade considerations, see: http://www.shorewall.net/upgrade_issues.htm -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] It Works!!
I have got it going! A three interface Bering. And I guess it should have been easier than I made it seem but thanks a lot for your help. Lynn, I gave up on uDHCP and reinstalled the default Pump and DHCP and everything works fine. For my next project I will make a bootable CD version and set up SSH on that. So we will meet again. Thanks again. David Pitts IT Services Manager Reid Library University of Western Australia Telephone: (08) 9380 3492 Fax: (08) 9380 1012 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall vs. Dachstein
Thanks for your responses. After spending more time on their website, I discovered their "Any-Firewall-Whitepaper" where it states that I actually don't have a problem since their technology works transparent to firewalls and NAT. Lynn, you are correct. There are some high UDP ports, but according to their white-paper, these are only "outgoing" connections. Since it's a peer-to-peer connection, I'm not sure how both parties can have outgoing connections, and no incoming connections...but its obviously some highly advanced technology! What's my exposure when opening those TCP and UDP ports? I'm VERY new to iptables, so be gentle. Thanks, Sean Snip--- The solution was posted on their website. Apparently by default it uses dynamic UDP and TCP but there is a static port patch for v2.2 located here: http://www.eyeballchat.com/download/patches/fixed_ports_patch22.reg Then you need to open up these ports: - UDP ports 5700, 5701 and 5702 and - TCP ports 5500 and 5501. Eyeball Chat should then work correctly. snip--- I use an app, EyeBall chat, to video chat to relatives. > It worked just fine under Dachstein. It is NOT working under Bering. > It appears the app uses a number of dynamic UDP and TCP connections for > the audio/video portions of the chat. I didn't see anything in the > shorewall logs that was helpful. Anyone got any thoughts? Snip--- I would imagine that since it worked with Dachstein, there was probably some high port UDP traffic that iptables stops with conntrack (statefule connection tracking). -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] IPsec routing
Charles Charles Steinkuehler wrote the following at 22:56 11.02.2003: The routes might puzzle you, but they are correct. Bingo, thanks, sometimes it helps if someone explains netmasks... :-( Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] IPsec routing
Erich Titl wrote: Hi I am planning ro route a remote location on a wireless link through a ipsec tunnel to the internet. The set up specifies a 0.0.0.0/0 subnet behind the tunnel, but this is what I get in the route after issuing ipsec start. This is on Bering 1_0.stable 2.4.18 before ipsec start # ip route 192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.1 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.2 default via 192.168.10.1 dev eth1 gatekeeper: -root- # /etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.97... ipsec_setup: Using /lib/modules/ipsec.o gatekeeper: -root- # ip route 192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.1 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.2 192.168.10.0/24 dev ipsec0 proto kernel scope link src 192.168.10.2 0.0.0.0/1 via 192.168.10.1 dev ipsec0 128.0.0.0/1 via 192.168.10.1 dev ipsec0 default via 192.168.10.1 dev eth1 now the 0.0.0.0/1 and 128.0.0.0/1 routes puzzle me, here is ipsec.conf The routes might puzzle you, but they are correct. The IPSec scripts implement a "route to everything on the internet" tunnel this way to insure the more specific /1 routes through the VPN take precedence over any /0 default route you may (or may not) have in place. It's a simple safety measure to insure no unencrypted traffic is sent out by mistake. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Aliasing IP Addres : HOWTO do ?
Francois BERGERET wrote: Hi Leaf friends, I don't understand how to have a second IP address on the same interface. I have hear some sound about aliasing... I have searched but not trieve exactly hot to do, and a real example. If somebody knows... I have already 192.168.73.254/24 on this NIC, but I want also 44.151.100.254/24. In the current linux world (2.2 or 2.4 kernel with iproute2), you simply add the address to the interface: ip addr add 44.141.100.254/24 broadcast + dev ethX Follow this with "ip addr" and "ip route" to verify the new IP address has been added correctly, along with a route to it's subnet. Details on configuring this to happen automatically at startup, and modifying any firewall rules as required are distribution specific, and you failed to mention which distribution you are running. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Aliasing IP Addres : HOWTO do ?
On Tuesday 11 February 2003 03:17 pm, Francois BERGERET wrote: > Hi Leaf friends, > > I don't understand how to have a second IP address on the same > interface. > I have hear some sound about aliasing... > I have searched but not trieve exactly hot to do, and a real example. > > If somebody knows... eth0:0 192.168.73.254/24 on this NIC eth0:1 44.151.100.254/24. There are quite a few posts in the leaf-user archives on this as well. -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] IPsec routing
Hi I am planning ro route a remote location on a wireless link through a ipsec tunnel to the internet. The set up specifies a 0.0.0.0/0 subnet behind the tunnel, but this is what I get in the route after issuing ipsec start. This is on Bering 1_0.stable 2.4.18 before ipsec start # ip route 192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.1 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.2 default via 192.168.10.1 dev eth1 gatekeeper: -root- # /etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.97... ipsec_setup: Using /lib/modules/ipsec.o gatekeeper: -root- # ip route 192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.1 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.2 192.168.10.0/24 dev ipsec0 proto kernel scope link src 192.168.10.2 0.0.0.0/1 via 192.168.10.1 dev ipsec0 128.0.0.0/1 via 192.168.10.1 dev ipsec0 default via 192.168.10.1 dev eth1 now the 0.0.0.0/1 and 128.0.0.0/1 routes puzzle me, here is ipsec.conf # basic configuration config setup # THIS SETTING MUST BE CORRECT or almost nothing will work; # %defaultroute is okay for most simple cases. #interfaces=%defaultroute interfaces="ipsec0=eth1" # Debug-logging controls: "none" for (almost) none, "all" for lots. klipsdebug=none plutodebug=none # Use auto= parameters in conn descriptions to control startup actions. plutoload=%search plutostart=%search # Close down old connection when new one using same ID shows up. uniqueids=yes # defaults for subsequent connection descriptions conn %default # How persistent to be in (re)keying negotiations (0 means very). keyingtries=0 conn valleygate-mountaingate type=tunnel auth=esp authby=secret keyexchange=ike left=192.168.10.1 leftsubnet=0.0.0.0/0 leftfirewall=yes right=192.168.10.2 rightsubnet=192.168.20.0/24 rightfirewall=yes disablearrivalcheck=no auto=start Any thoughts Thanks Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Aliasing IP Addres : HOWTO do ?
Hi Leaf friends, I don't understand how to have a second IP address on the same interface. I have hear some sound about aliasing... I have searched but not trieve exactly hot to do, and a real example. If somebody knows... I have already 192.168.73.254/24 on this NIC, but I want also 44.151.100.254/24. Some idea ? TIA. Best Regards, Francois BERGERET, France. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] upgrading to stable bearing release
Hey guys ... been running Bearing Kernel:Linux version 2.4.18 (bering5@debian) (gcc version 2.95.2 and ... i know i know (not supposed tooo) installed to hard drive because of packages. What do i need to do to upgrade to the stable release of bearing? Also running Shorewall 1.2.8. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Re: [Shorewall-users] Shorewall and Bridged VTUN
Hugues Belanger wrote: Hi Don't understand why I'm getting so much flake about posting on this list ? The fact that I user Bering as a distro does matter I could have done the same with gentoo or RedHat. The problem I'm having is with shorewall configuration not Bering. Hugues -- you are asking for free support for free products. Is it too much to ask of you in return that you follow the procedure that we have established for supporting Shorewall under Leaf? Anyhow here's my routing table 1.1.1.1 is the external interface Routing Table 192.168.96.0/24 dev br0 proto kernel scope link src 192.168.96.100 1.1.1.0/24 dev eth0 proto kernel scope link src 1.1.1.1 default via 1.1.1.2 dev eth0 Interface configuration --- 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: dummy0: mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:01:03:2b:bf:f4 brd ff:ff:ff:ff:ff:ff inet 1.1.1.1/24 brd 1.1.1.255 scope global eth0 4: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:01:03:2b:c7:44 brd ff:ff:ff:ff:ff:ff 5: tap0: mtu 1450 qdisc noqueue link/ether fe:fd:00:00:00:00 brd ff:ff:ff:ff:ff:ff 6: br0: mtu 1500 qdisc noqueue link/ether 00:01:03:2b:c7:44 brd ff:ff:ff:ff:ff:ff inet 192.168.96.100/24 brd 192.168.96.100 scope global br0 Bridge configuration after VTUN is establish - brctl show bridge name bridge id STP enabled interfaces br0 8000.0001032bc744 yes eth1 tap0 Here is my guess and I must stress that it is only a guess: a) I would define the local zone to be associated with eth1 and tap0 and I would have a loc->loc ACCEPT policy. b) I would associate the 'net' zone with eth0. c) I would define an OpenVPN tunnel in /etc/shorewall/tunnels. openvpn net The default for open VPN is to use UDP port 5000 for both ends so it sounds like it's compatible with would you have. d) The remainder of your rules can be adjusted to suit your needs. Let _us_ know how that works... -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Using a wireless router with LEAF (Dachstein, Bering)
At 01:16 PM 2/11/03 -0600, Charles Steinkuehler wrote: Ray Olszewski wrote: The basic problem remains -- you need to make the wireless LAN itself secure. To do that, you have the following options (that I can think of - can someone suggest others?): Remove "wireless" from the above, and I completely agree with you. I started a thread today on the FreeS/WAN about network security when any user can go to Best Buy and for $50 buy a WAP and connect it to their desktop, in the process making the "physical security" model so prevelent in today's firewall systems as obsolete as buggy whips. [rest deleted] You're correct, of course ... I was thinking, as I usually do, in terms of networks small enough that the network manager had good physical control of what was on them. (My main focus these days is home LANs.) That is often not the case, once you move to moderately large LANs. But by the time you get to that size, you should have a management model in place that protects, preferably unobtrusively, against malicious (as well as just careless or stupid) employees anyway ... right? In these cases, good controls over the LAN are needed. Ingredients include: 1. Using only switches at all locations controlled by the netadmin (locked equipment closets and the locked server room), to inhibit sniffing opportunities. 2. MAC-address authentication. (I think there are switches that can implement this on a port-by-port basis, which would inhibit spoofing possibilities and prevent "informal" addition of hubs and WAPs that turn a single port into a connection for multiple machines.) 3. Maintaining security on servers and workstations ... don't rely on the Internet firewall to secure unpatched applications. 4. Using encryption on the LAN for anything that needs to be confidential (including anything that involves passwords). Unfortunately, standard practice does lag behind good practice, making it good to discuss these issues from time to time. And thanks for the references to the authentication packages. I actually worked briefly in this area, about 18 months ago. Unsuccessfully, though ... the client even stiffed us after we completed the proof-of-principle demo implementation. It's a tricky thing to get right, and I think the client concluded he could not make money using what we had developed. -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Using a wireless router with LEAF (Dachstein, Bering)
Ray Olszewski wrote: The basic problem remains -- you need to make the wireless LAN itself secure. To do that, you have the following options (that I can think of - can someone suggest others?): Remove "wireless" from the above, and I completely agree with you. I started a thread today on the FreeS/WAN about network security when any user can go to Best Buy and for $50 buy a WAP and connect it to their desktop, in the process making the "physical security" model so prevelent in today's firewall systems as obsolete as buggy whips. There are useful methods for securing wireless (or other "untrusted") networks from other networks, but very little for preventing wireless to wireless hacking, or a wireless user attacking other user machines if someone installs a rogue WAP. 1. WEP encryption. The consensus of opinion seems to be that this works against casual break-ins, but not against determined ones. (Peter provided a link to one WEP cracker; another is airsnort.) Appallingly insecure, but it should still be enabled. It provides some measure of protection from wireless-wireless hacking the more centralized solutions below don't, and at the very least forces someone to break the new "cyber-terrorist" laws if they actually do decode your WAP key and start sniffing around your network. 2. MAC address control, implemented either in the WAP itself (however it does this) or in the LEAF router (as DHCP restrictions). Works as long as a break-in attempt does not manage to spoof an allowed MAC address. Spoofing MAC's from sniffed traffic is too easy for this to provide much protection. When used in conjunction with another authentication system, it can be useful. 3. Some other authentication mechanism for hosts. Possibilities are requiring use of an ssh tunnel or some form of IPSec. This slows down the wireless LAN but probably provides good security (though the mechanisms for doing this may not be available off the shelf). 4. Service-level restrictions. The options available to you here (e.g., proxy servers, user-side certificates, pop-before-smtp checks on outgoing mail, SSL and ssh connections to LAN hosts) depend on how much you are willing to limit what legit users of the WAP LAN can do. I haven't yet implemented a "real" WAP LAN here; I have just started experimenting with an isolated lab-bench one. So I offer these thoughts more as a first pass at the problem than as anything definitive, more designed to clarify the issues than to settle anything. I am quite interested in any better ideas that others can offer. You might want to check out nocatauth (provide wireless internet service only to folks who authenticate) and WaveSec (locks down the wireless lan pretty tight using IPSec, with patched versions of DHCP server/client to register public keys/certs with DNS): http://nocat.net/ http://www.wavesec.org/ Both provide pretty decent solutions from the free (as in beer and speech) software side. There are various commercial pakages available as well, but I have yet to see any real workable solution (commercial or open-source) that can protect a LAN if a WAP is plugged in without permission...the layer 2 ethernet security is just based too strongly on the physical security model. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Dachstein Port Forwarding
At 10:06 AM 2/11/03 -0800, Doug Sampson wrote: Ray/Charles, I was afraid you'd both still point to the TCP/IP settings of the Exchange box as the cause for the failure. I had thought that scanning a range of ports was to check if it was open. But it looks like my assumption was wrong. It checks for responses and obviously the scanner isn't getting a proper response from port 25. What layer does the scanning work on? Layer 3 or higher (especially the application layer?) of the OSDI model? "The" scanner works on whatever it chooses to. Most actual scanners I am familiar with test at the network (IP address - OSDI 3) and transport (TCP, UDP port - OSDI 4) layers. The usual standard for "open" (at least for TCP) is that something at that IP address responds at that port (instead of an icmp failure packet or no response at all). I don't use scanners that identify "stealth" ports, so I'm not sure what qualifies for that ... maybe silence instead of one of the standard "Connection Refused" responses (but you'd have to look at the docs for the actual scanner you are using to be sure). Since this Exchange box is active, I cannot change the IP settings until after hours. We're mainly Linux experts here, not Windows experts here (at least that is true of me), so at some point you're going to need to turn elsewhere for detailed help with the Exchange setup. And you've never described the proxy server (and I don't exactly know how a proxy server proxies SMTP anyway, except by running its own MTA), so we can't advise you about it. But ... the ONLY change we are suggesting you make is to the Exchange server's default gateway. Does that *really* require a reboot on Windows? (I know the old joke about "You have moved your mouse - press any key to reboot", but surely Microsoft has make networking reconfiguration a bit more sane by now). OR does the proxy server require that it be the default gateway to function (if so, in what sense does it proxy)? I also would need to change the MX record settings on our external DNS server. I wonder if there's a neat trick one can do to ensure no loss of email during this phase? For example, I could create a new MX record for the Dachstein router leaving the original MX record in place but assigning a different priority to the new MX record. When external mail server checks for MX records, they would attempt to contact our mail server with the first MX setting and failing that, check the next MX record and find the mail server active at that MX record. Does this make sense? Is this do-able? Should the MX record contain the name of the router port-forwarding the mail to the Exchange box instead the name of the Exchange box? In principle, this approach should work just fine for not dropping mail. But remember to do it far enough in advance so that the change propagates to cached records elsewhere. And consider if the Exchange server itself requires any special reconfiguration. The added MX record should point to an FQN that is externally resolvable to the router's IP address. A quick check of your MX records says that you already have external MX backups: autovcr@waverly:~$ host -t MX dawnsign.com dawnsign.comMX 20 smtp.easydns.com dawnsign.comMX 30 smtp2.easydns.com dawnsign.comMX 0 mercury.dawnsign.com dawnsign.comMX 10 mail.dawnsign.com Both the 0 and 10 entries point to your proxy-server IP address. But if the 20 and 30 entries are functional, they should protect you against e-mail loss during your test phase. But before you go on with this ... why do you need this Exchange server to be reachable both via the old proxy server and via the new Dachstein router? Is it just a transition issue, or is there something more fundamental that requires this duplication? Why not handle everything through suitable MX entries that get all mail to a single IP address? -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Using a wireless router with LEAF (Dachstein, Bering)
at Tuesday, February 11, 2003 5:47 PM, Jeff Newmiller <[EMAIL PROTECTED]> was seen to say: >> Since security is a major concern when attached to the Internet, why >> not make use of the three-interface firewall solution within >> Bearing/Shorewall and place the wireless access point on that third >> interface of the firewall within the DMZ? >> Maybe I'm overlooking a "barn-door" security breach, but it just >> seems logical to use your wireless devices on "that" interface, and >> routing traffic accordingly. >> Anyone else have any thoughts on this? > A DMZ is not an appropriate place for a workstation in most cases. > Machines on a DMZ should be regarded as potential sacrificial lambs, > and kept isolated from the rest of your local network. This is not > normally acceptable for workstation use. A dmz is a perfectly acceptable place to put a wireless hub - you definitely don't want it to have unrestricted access to the main lan, but you don't want it on the internet either. In fact, if you consider your lan traffic at all sensitive, I could recommend blocking all but IPSEC from the wireless hub - the wireless devices can use a vpn client to connect "inwards" and you have all the convenience of wireless networking with the security of a decent encryption setup (and of course that allows those workstations (presumably laptops) to be used across the internet too) If your lan isn't that sensitive, that is probably overkill though :) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Dachstein Port Forwarding
Ray/Charles,
I was afraid you'd both still point to the TCP/IP settings of the Exchange
box as the cause for the failure. I had thought that scanning a range of
ports was to check if it was open. But it looks like my assumption was
wrong. It checks for responses and obviously the scanner isn't getting a
proper response from port 25. What layer does the scanning work on? Layer 3
or higher (especially the application layer?) of the OSDI model?
Since this Exchange box is active, I cannot change the IP settings until
after hours. I also would need to change the MX record settings on our
external DNS server. I wonder if there's a neat trick one can do to ensure
no loss of email during this phase? For example, I could create a new MX
record for the Dachstein router leaving the original MX record in place but
assigning a different priority to the new MX record. When external mail
server checks for MX records, they would attempt to contact our mail server
with the first MX setting and failing that, check the next MX record and
find the mail server active at that MX record. Does this make sense? Is this
do-able? Should the MX record contain the name of the router port-forwarding
the mail to the Exchange box instead the name of the Exchange box?
Thanks for all of your help!
~Doug
> I agree with Ray that the place to look now is your Exchange
> machine's
> network configuration. Please understand that just because
> GRC reports
> your port 25 as "stealth" doesn't mean the packets are being
> firewalled.
> What it means is that the GRC system sent out a TCP packet
> to port 25
> at your IP and didn't get a response back. From the firewall
> information it looks like the packets are passing through
> your Dachstein
> firewall, which means either you've got port-forwarding setup to the
> wrong IP, the exchange server isn't really running, or the exchange
> server is incorrectly sending back the reply packets (ie
> sending them to
> the proxy-server instead of the Dachstein router).
>
> Make sure the exchange server is using Dachstein as it's default
> gateway, and I think everything will begin working. If you
> continue to
> have problems, post the network confiuration ("ipconfig /all"
> and "route
> print") from the Exchange box for debugging.
>
> --
> Charles Steinkuehler
> [EMAIL PROTECTED]
>
>
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Using a wireless router with LEAF (Dachstein, Bering)
--- Jeff Newmiller <[EMAIL PROTECTED]> wrote: > On Tue, 11 Feb 2003, Danny Carter wrote: > > Since security is a major concern when attached to the Internet, why not > > make use of the three-interface firewall solution within > > Bearing/Shorewall and place the wireless access point on that third > > interface of the firewall within the DMZ? > > A DMZ is not an appropriate place for a workstation in most cases. > Machines on a DMZ should be regarded as potential sacrificial lambs, and > kept isolated from the rest of your local network. This is not normally > acceptable for workstation use. pn] Exactly. My notebook PC is currently on my internal private network, and it needs to remain there to be useful. Putting it on a DMZ isolates it from the network resources I need, and adding port-forwarding rules to restore them defeats the purpose of using the DMZ. pn] My personal conclusion is that wireless connections are not yet secure enough for my comfort. = - Peter Nosko ([EMAIL PROTECTED]) This is a good place for a tagline. __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Using a wireless router with LEAF (Dachstein, Bering)
At 09:35 AM 2/11/03 -0800, Danny Carter wrote: Since security is a major concern when attached to the Internet, why not make use of the three-interface firewall solution within Bearing/Shorewall and place the wireless access point on that third interface of the firewall within the DMZ? Maybe I'm overlooking a "barn-door" security breach, but it just seems logical to use your wireless devices on "that" interface, and routing traffic accordingly. Anyone else have any thoughts on this? [old stuff deleted] Whether this works or not depends on (a) what you want the wireless LAN to do and (b) what you want to protect from it. Normally, hosts on a DMZ cannot initiate connections either to the Internet or to the (wireline, in this case) LAN. The ruleset covering the DMZ interface may open particular holes ... to allow DNS inquiries, for example ... but the basic role of a DMZ is to respond to traffic from the Internet or the LAN. So putting a WAP on the DMZ will not allow the WAP hosts to have normal access to the Internet. But what if you use a separate, "normal" LAN interface for the WAP, rather then an interface configured as a DMZ? Again, it depends. If someone breaks the security on the WAP LAN, he or she will be able to do whatever legitimate users there can do (use it to send SPAM? access hosts on the wireline LAN? download porn? it depends on how much you trust yourlegit users not to use the connection in disapproved ways). The basic problem remains -- you need to make the wireless LAN itself secure. To do that, you have the following options (that I can think of - can someone suggest others?): 1. WEP encryption. The consensus of opinion seems to be that this works against casual break-ins, but not against determined ones. (Peter provided a link to one WEP cracker; another is airsnort.) 2. MAC address control, implemented either in the WAP itself (however it does this) or in the LEAF router (as DHCP restrictions). Works as long as a break-in attempt does not manage to spoof an allowed MAC address. 3. Some other authentication mechanism for hosts. Possibilities are requiring use of an ssh tunnel or some form of IPSec. This slows down the wireless LAN but probably provides good security (though the mechanisms for doing this may not be available off the shelf). 4. Service-level restrictions. The options available to you here (e.g., proxy servers, user-side certificates, pop-before-smtp checks on outgoing mail, SSL and ssh connections to LAN hosts) depend on how much you are willing to limit what legit users of the WAP LAN can do. I haven't yet implemented a "real" WAP LAN here; I have just started experimenting with an isolated lab-bench one. So I offer these thoughts more as a first pass at the problem than as anything definitive, more designed to clarify the issues than to settle anything. I am quite interested in any better ideas that others can offer. -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Using a wireless router with LEAF (Dachstein, Bering)
On Tue, 11 Feb 2003, Danny Carter wrote: > Since security is a major concern when attached to the Internet, why not > make use of the three-interface firewall solution within > Bearing/Shorewall and place the wireless access point on that third > interface of the firewall within the DMZ? > Maybe I'm overlooking a "barn-door" security breach, but it just seems > logical to use your wireless devices on "that" interface, and routing > traffic accordingly. > Anyone else have any thoughts on this? A DMZ is not an appropriate place for a workstation in most cases. Machines on a DMZ should be regarded as potential sacrificial lambs, and kept isolated from the rest of your local network. This is not normally acceptable for workstation use. [...] --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Using a wireless router with LEAF (Dachstein, Bering)
Since security is a major concern when attached to the Internet, why not make use of the three-interface firewall solution within Bearing/Shorewall and place the wireless access point on that third interface of the firewall within the DMZ? Maybe I'm overlooking a "barn-door" security breach, but it just seems logical to use your wireless devices on "that" interface, and routing traffic accordingly. Anyone else have any thoughts on this? Regards, Danny Carter On Tue, 11 Feb 2003, Peter Nosko wrote: > > --- Todd Pearsall <[EMAIL PROTECTED]> wrote: > > The security is fair at best on all of the consumer targeted wireless > > devices I've seen. 128-256bit encryption and some routers will let you > > limit access to pre-defined MAC addresses only (my D-Link doesn't). So > > pn] Hmmm. I found this and think I will remain tethered to cat5e cable > for the time being. > > http://wepcrack.sourceforge.net > > pn] Thanks all for your help! > > = > > - > Peter Nosko ([EMAIL PROTECTED]) > This is a good place for a tagline. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Using a wireless router with LEAF (Dachstein, Bering)
--- Todd Pearsall <[EMAIL PROTECTED]> wrote: > The security is fair at best on all of the consumer targeted wireless > devices I've seen. 128-256bit encryption and some routers will let you > limit access to pre-defined MAC addresses only (my D-Link doesn't). So pn] Hmmm. I found this and think I will remain tethered to cat5e cable for the time being. http://wepcrack.sourceforge.net/ pn] Thanks all for your help! = - Peter Nosko ([EMAIL PROTECTED]) This is a good place for a tagline. __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] How secure am I now that I am running Bering?
Questions like yours are almost impossible to answer. The reasons:
1. You are not sure about the destination ports involved.
2. You don't report the source ports involved.
3. You include cryptic references to system behavior you do not describe
("Discounting PC crash and power cuts", whatever that means ... are you
saying these things happened coincident with the troublesome traffic? or
that they did not happen?).
With those disclaimers understood ...
A. Whether the logs indicate an attack or not, they do not suggest a
*successful* attack. Unless, of course, you saw system or connectivity
failures that you did not tell us about.
B. Port scans are a commonplace on the Internet. Personally, I can't be
bothered dealing with them, beyond having a good firewall and secure
service daemons in place. If you use LaBrea, do you really intend to spend
time reviewing its results regularly?
C. For security updates, you are pretty much dependent on Jacques keeping
Bering up to date, unless you want to install your own Bering development
system (there are Bering docs about this on the LEAF site) and recompile
apps yourself. (If you do, be sure to pass them on to Jacques, since there
is no point in duplicating this effort.)
D. Bering's logging behavior is pretty standard for Unix/Linux, controlled
by /etc/syslog.conf . To reduce or remove duplicate logging, edit it (then
back up etc.lrp). You can also modify what packets are logged at all
through Shorewall, but a Shorewall user (rather than me) is going to have
to supply the details.
At 12:12 PM 2/11/03 +, James Neave wrote:
Hi,
In the last few days I have had some arseholes beating on my Bering box,
sending 1000's of UDP packets at one port and such like.
It filled the logs, but that was it. Then I blacklisted the IPs.
A few questions about this.
--
The denied packets were logged in messages, syslog and a third log that
I forget the name of, the Daemon log I think.
It ran out of space at 2500 denied messages.
How can I make it only log to one of these files to save space?
They beat on port 39967 (not *entirely* sure about that number), is that
significant? Or was it just a failed DoS attack?
--
Something strange happened this morning.
Last night a dozen IPs sent 360 odd packets to another port, round about
13300, but this morning the log was back down to 9 packets. This only
*might* have been an attack, It could have something to do with me
resuming my use of ICQ.
Discounting PC crash and power cuts, could this be a sign of a
successful attack? My PC is on at home right now and I'm a little
worried. There is NO remote access to the firewall with no sshd or
telnetd running.
I have a couple of non-standard ports forwarded to my local IP, but so
far nobody has scanned all my ports, just 2, possibly 3 occurrences of
people beating on the 'wall.
--
How can I keep my firewall up to date with the latest security fixes?
--
I'm going to install LaBrea when I get home, a good idea, yes? Will it
work on 2.4 kernels?
--
Argh, now I'm sitting at work panicking
--
---"Never tell me the odds!"
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
---
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Non-FPU Kernels
On Tuesday 11 February 2003 04:38 am, Nick Taylor wrote: > Thanks for this Lynn. > > Just to clarify - Can I use the Dachstein Image together with the > 2.2.16-1-386-NoFPU kernel? > > I ask because it seems that the kernel in the image is 2.2.19, and > I'm wondering if the older one will work? > > Is this my only option? Could Bering work in this setup? Yes, the older 2.2.16 kernel will work. I'm not aware of a non-FPU kernel for Bering, but there may possibly be one buried somewhere at: http://leaf.sourceforge.net/devel/jnilo -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Dachstein Port Forwarding
Doug Sampson wrote:
No, Dachstein isn't replacing anything that used to exist at that address. I
am still running a Proxy Server 2.0 at that address and it shows port 25 and
80 being open. Running a port scanner from outside the network against the
Dachstein router shows only port 80 (and 22) as being open. You can try
scanning against 216.70.236.236 (Dachstein) and see for yourself. Try the
same scan against 216.70.236.235 (the Proxy Server) and you will notice that
ports 25 and 80 are open.
All evidence points to the Dachstein router. Ray, I understand what you're
saying about the firewall being correctly configured- it does seem like it
is. But the port scanner isn't reporting port 25 as being open.
I agree with Ray that the place to look now is your Exchange machine's
network configuration. Please understand that just because GRC reports
your port 25 as "stealth" doesn't mean the packets are being firewalled.
What it means is that the GRC system sent out a TCP packet to port 25
at your IP and didn't get a response back. From the firewall
information it looks like the packets are passing through your Dachstein
firewall, which means either you've got port-forwarding setup to the
wrong IP, the exchange server isn't really running, or the exchange
server is incorrectly sending back the reply packets (ie sending them to
the proxy-server instead of the Dachstein router).
Make sure the exchange server is using Dachstein as it's default
gateway, and I think everything will begin working. If you continue to
have problems, post the network confiuration ("ipconfig /all" and "route
print") from the Exchange box for debugging.
--
Charles Steinkuehler
[EMAIL PROTECTED]
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bizarre behaviour in wisp dist?
From: "Vladimir I." <[EMAIL PROTECTED]> Samuel, Try pinging with large packets and tell me if you experience any packet loss. Ok, putting large packets i experience a huge number of packet loss, here is the output: # ping 200.253.xxx.xxx -s 504 PING 200.253.xxx.xxx (200.253.xxx.xxx): 504 octets data 512 octets from 200.253.xxx.xxx: icmp_seq=8 ttl=254 time=29.7 ms 512 octets from 200.253.xxx.xxx: icmp_seq=11 ttl=254 time=33.5 ms 512 octets from 200.253.xxx.xxx: icmp_seq=16 ttl=254 time=24.8 ms 512 octets from 200.253.xxx.xxx: icmp_seq=26 ttl=254 time=23.0 ms 512 octets from 200.253.xxx.xxx: icmp_seq=34 ttl=254 time=151.8 ms 512 octets from 200.253.xxx.xxx: icmp_seq=38 ttl=254 time=22.2 ms --- 200.253.xxx.xxx ping statistics --- 39 packets transmitted, 6 packets received, 84% packet loss round-trip min/avg/max = 22.2/47.5/151.8 ms with -s 440 i don't have packet loss, just with -s 504! =/ Also, is there any chance that you might have a routing loop? A diagram might help. Ok, a quickly poor diagram: Internet <-->Router <--> linux_firewall <--> AP-1000 <--> wisp station <--> wisp station 2 eths netcs0-1, netcs0, eth0 eth0 I check all my route, and i don't find nothing that inidicates a looping route Another thing to check - assign an IP address from a different network on netcs0. That's the big problem, i can't assign another ip, cos to reach it i have to use AP-1000, and it i can't change, cos of others stations already connected! Really thanks for the help! Samuel Abreu _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering uClibc - ulogd: load_plugins: /usr/lib/ulogd/ulog_*.so- File not found
Laurentiu Drob wrote:
>
Hi Eric,
The bug with "File not found" is solved. It's from uClibc dynamic
loader. The few steps for solving it are:
1)compile postgresql using uClibc [I mean all staging_dir stuff] and
install the client [for blah/blah/blah/include and lib dependencies].
2) Change the following lines in ulogd.c function load_plugin(...)
if (!dlopen(file, RTLD_NOW)) {
with
if (!dlopen(file, RTLD_GLOBAL)) {
3) Put libpq* libraries in /lib or set LD_LIBRARY_PATH to point them
et voila!
Or you may consider to run ulogd this way:
[blah@blah blah]#LD_PRELOAD=/where/is/libpq.so.3 ulogd -d
Thanks God for this :)
Best regards,
lwd.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] How secure am I now that I am running Bering?
Hi, In the last few days I have had some arseholes beating on my Bering box, sending 1000's of UDP packets at one port and such like. It filled the logs, but that was it. Then I blacklisted the IPs. A few questions about this. -- The denied packets were logged in messages, syslog and a third log that I forget the name of, the Daemon log I think. It ran out of space at 2500 denied messages. How can I make it only log to one of these files to save space? They beat on port 39967 (not *entirely* sure about that number), is that significant? Or was it just a failed DoS attack? -- Something strange happened this morning. Last night a dozen IPs sent 360 odd packets to another port, round about 13300, but this morning the log was back down to 9 packets. This only *might* have been an attack, It could have something to do with me resuming my use of ICQ. Discounting PC crash and power cuts, could this be a sign of a successful attack? My PC is on at home right now and I'm a little worried. There is NO remote access to the firewall with no sshd or telnetd running. I have a couple of non-standard ports forwarded to my local IP, but so far nobody has scanned all my ports, just 2, possibly 3 occurrences of people beating on the 'wall. -- How can I keep my firewall up to date with the latest security fixes? -- I'm going to install LaBrea when I get home, a good idea, yes? Will it work on 2.4 kernels? -- Argh, now I'm sitting at work panicking Cheers, Jim. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bizarre behaviour in wisp dist?
Samuel, Try pinging with large packets and tell me if you experience any packet loss. Also, is there any chance that you might have a routing loop? A diagram might help. Another thing to check - assign an IP address from a different network on netcs0. Samuel Abreu wrote about "Re: [leaf-user] Bizarre behaviour in wisp dist?": > Ok, detailing more! > > That particular station, have 3 interfaces, netcs0, netcs1 and eth0 > all with same ip! and with parprouted on! > netcs0 is connected to one Orinoco AP1000, both with Orinoco Gold Cards, > netcs1 is a Orinoco Gold Card, and is connected to another wisp station, > with one orinoco gold! > eth0 is connected to a Red Hat! > > Ok, no packet loss, signal is excelent, in both connections! > The bizarre part, when i try to log-in via telnet in the side of my lan, > that use the AP-1000 to reach that station, i just can't get the menu, it > stops and don't get more response in the telnet! Sometimes, when i put the > password and hit Ctrl+c, i fall directly in the console... not always work, > but with some persistency! > Now, going via eth0 i don't know, i don't have the oportuni to test! > But in the station that is connected in netcs1, and all the computer that > stay in that wisp station (The one connected in netcs1), i can get the menu! > In the station with 3 interfaces and in the stations that's is connected to > that machine via netcs1, but out of it, via internet or via the next hop > after AP-1000 in my lan, i can't log-in! =(( > > I change the SBC, change the wisp version and the problem persists! > But i do not change the pcmcia slot, so is my next try, i don't seem solving > my problem! but i have to try something! > > Samuel Abreu -- Best Regards, Vladimir Systems Engineer (RHCE) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Non-FPU Kernels
Thanks for this Lynn. Just to clarify - Can I use the Dachstein Image together with the 2.2.16-1-386-NoFPU kernel? I ask because it seems that the kernel in the image is 2.2.19, and I'm wondering if the older one will work? Is this my only option? Could Bering work in this setup? Regards Nick > -Original Message- > From: Lynn Avants [mailto:[EMAIL PROTECTED]] > Sent: 11 February 2003 03:07 > To: [EMAIL PROTECTED] > Subject: Re: [leaf-user] Non-FPU Kernels > > > On Monday 10 February 2003 07:40 pm, Nick Taylor wrote: > > I've been inspecting the various versions of LEAF, and can't > > readily identify which of them might work in my 486SX, i.e. Non-FPU. > > > > I'm quite interested in the Bering, Dachstein, and Oxygen > > distributions. > > > > Could someone let me know which of these would work in my ancient > > machine? > > Charles has some non-FPU kernels for Dachstein at: > http://leaf.sourceforge.net/devel/cstein > -- > ~Lynn Avants > Linux Embedded Firewall Project developer > http://leaf.sourceforge.net > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > -- > -- > leaf-user mailing list: [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-user > SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
