Linux-Development-Sys Digest #330, Volume #8 Thu, 7 Dec 00 13:13:10 EST
Contents:
wavelan +encrypt (Max Ischenko)
Re: Problem with LVM and LILO (David Vidal Rodriguez)
Problem getting ip_forwarding to work (David Ronis)
Re: Great reply; this guy needs a life (Kaz Kylheku)
bridging for 2.4.0-testx (Bart De Schuymer)
How to access PCI configuration registers ([EMAIL PROTECTED])
log message from linuxrc script (Jerome Corre)
----------------------------------------------------------------------------
From: Max Ischenko <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: wavelan +encrypt
Date: 7 Dec 2000 17:46:10 +0200
Is there a way to use encrypted stream with wavelan card?
Problem is to setup encryption key for the card.
I've search the Web but didn't find it.
I have 2.2.16 kernel (RH 7.0)
--
No wonder Clairol makes so much money selling shampoo.
Lather, Rinse, Repeat is an infinite loop!
------------------------------
From: David Vidal Rodriguez <[EMAIL PROTECTED]>
Subject: Re: Problem with LVM and LILO
Date: Thu, 07 Dec 2000 17:28:34 +0100
Bruce Stephens wrote:
> I don't know. Try the LVM web site, and the mailing lists there.
> Personally, I kept my root partition and /boot as ordinary partitions.
> If you have any ordinary partitions (for example, the root partition),
> you should be able to stick kernel images on one of those and use
> LILO. Even an MSDOS partition ought to work, I think, so long as
> you're careful not to defragment the partition.
I have carefully read the documentation & FAQs of LVM and they say
explicitly that it is possible to mount a root LVM. I have such a root,
indeed. The problem appears when lilo looks for devices recursively in /dev
- it could also have to do with the lvm-module itself: I don't know much
about the kernel internals, but it could be possible that a module that uses
a specific special device (major-minor pair) registers it into the kernel as
a valid device of some sort - in this case, a disk, partition, or something
thar can contain a filesystem.
I imagine a possibility of going around the problem, and this is the use of
a so-called partition alias. I have read that a partition can overlap with
another though that does not make much sense, but it is useful for the
following case:
You have a LV from which you know the exact location and length (in units of
physical sectors;
that information is given by the program pvdisplay -v). It has to be fully
contained within a partition and be contiguous (just like a normal
partition). Then you can define a partition with sfdisk -uS -N <number>
/dev/hda<number> which points exactly to the beginning and end of the LV.
Now you have a partition alias for the LV. Before working with lilo you
should mount the root-alias as /, work in the runlevel S and disable lvm.
The "root="-entry of the lilo.conf has to be a major-minor number - the one
of your LV- , and it should boot from your partition-alias.
That could be a work-around until lilo supports lvm. What do you think about
this approach?
--
------------------------------------------------------------------------
David Vidal R. ([EMAIL PROTECTED])
------------------------------
From: David Ronis <[EMAIL PROTECTED]>
Subject: Problem getting ip_forwarding to work
Crossposted-To: comp.protocols.ppp,comp.os.linux.networking
Date: Thu, 07 Dec 2000 17:03:14 GMT
Hi
I've been using pppd-2.3.11 on an i686-linux(2.2.17)-glibc(2.2) client
to connect to a Sun also running 2.3.11. I use a static IP number for
the client and an options file as shown below. This has worked for
years.
I'm trying to get a ppp server working on another linux box (same
software as the client) that is permanently connected to the net at
eth0 and has a ZyXEL omni 56K Plus modem connected to ttyS1. My
options file is appended below.
I can connect to the server and seem to have set routing up correctly
at the both ends:
netstat -rn gives
on my client:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
132.206.205.91 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 132.206.205.91 0.0.0.0 UG 0 0 0 ppp0
and on the server:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
132.206.205.86 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
132.206.205.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 132.206.205.10 0.0.0.0 UG 0 0 0 eth0
in addition /proc/sys/net/ipv4/ip_forward is 1 and rp_filter is 0
(both for ppp0 and eth0).
My problem is that I still can't seem to get out beyond the server
hosts. Well actually this isn't quite true; one or two local hosts
work but other ones don't and no machine beyond my subnet seem to be
reachable. For example, from the client
ping 132.206.205.98 works (an i586-linux(2.2.17)-gnu box)
ping 132.206.205.99 works (a Solaris box)
ping 132.206.205.97 fails (a Solaris box)
ping 132.206.205.10 fails (the gateway for the server machine).
The arp table is empty on the client, and contains the following on the server:
/sbin/arp -vn
Address HWtype HWaddress Flags Mask Iface
132.206.205.97 ether 08:00:20:12:77:C4 C eth0
132.206.205.99 ether 08:00:20:12:73:E0 C eth0
132.206.205.98 ether 00:E0:29:5E:B6:FA C eth0
132.206.205.10 ether 00:30:B6:36:50:10 C eth0
132.206.205.86 * * MP eth0
Entries: 5 Skipped: 0 Found: 5
For what it's worth, both of the machines I can ping are there, but so
are two of the ones I can't.
I upgraded pppd at both ends to 2.4.0b4 with identical results. In
addition, I've rebuilt the kernel (just to make sure that I'd really
chosen the correct options--I had) and again I get the same behavior.
Some of the relevant kernel configuration options are:
#
# Networking options
#
CONFIG_PACKET=m
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
# CONFIG_NETLINK_DEV is not set
# CONFIG_FIREWALL is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_TOS is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_ROUTE_LARGE_TABLES is not set
# CONFIG_IP_PNP is not set
# CONFIG_IP_ROUTER is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_ALIAS is not set
CONFIG_SYN_COOKIES=y
#
# (it is safe to leave these untouched)
#
# CONFIG_INET_RARP is not set
CONFIG_SKB_LARGE=y
Any suggestions?
Thanks in advance.
David
Here are the /etc/ppp/options files
On the server:
usehostname
noauth
modem
lock
crtscts
115200
proxyarp
on the client:
# /etc/ppp/options
#
# $Id: options,v 1.4 1996/05/01 18:57:04 alvar Exp $
#
# Originally created by Jim Knoble <[EMAIL PROTECTED]>
# Modified for Debian by alvar Bray <[EMAIL PROTECTED]>
# Modified for PPP Server setup by Christoph Lameter <[EMAIL PROTECTED]>
# Modified for Slackware by Pat Volkerding <[EMAIL PROTECTED]>
#
# Use the command egrep -v '#|^ *$' /etc/ppp/options to quickly see what
# options are active in this file.
# Specify which DNS Servers the incoming Win95 or WinNT Connection should use
# Two Servers can be remotely configured
# dns-addr 192.168.1.1
# dns-addr 192.168.1.2
# Specify which WINS Servers the incoming connection Win95 or WinNT should use
# wins-addr 192.168.1.50
# wins-addr 192.168.1.51
# Run the executable or shell command specified after pppd has
# terminated the link. This script could, for example, issue commands
# to the modem to cause it to hang up if hardware modem control signals
# were not available.
#disconnect "chat -- \d+++\d\c OK ath0 OK"
# async character map -- 32-bit hex; each bit is a character
# that needs to be escaped for pppd to receive it. 0x00000001
# represents '\x01', and 0x80000000 represents '\x1f'.
# asyncmap 0
# Require the peer to authenticate itself before allowing network
# packets to be sent or received.
# For a PPP Server with script based logins not using PAP or CHAP
# you need to disable this setting.
#auth
# Do not require the other end of the connection to authenticate itself.
# This option is dangerous if pppd is setuid.
# If you also have ethernet and are having problems getting PPP to connect
# over a modem, try this option.
noauth
# Use hardware flow control (i.e. RTS/CTS) to control the flow of data
# on the serial port.
crtscts
# Use software flow control (i.e. XON/XOFF) to control the flow of data
# on the serial port.
#xonxoff
# Specifies that certain characters should be escaped on transmission
# (regardless of whether the peer requests them to be escaped with its
# async control character map). The characters to be escaped are
# specified as a list of hex numbers separated by commas. Note that
# almost any character can be specified for the escape option, unlike
# the asyncmap option which only allows control characters to be
# specified. The characters which may not be escaped are those with hex
# values 0x20 - 0x3f or 0x5e.
#escape 11,13,ff
# Don't use the modem control lines.
#local
# Specifies that pppd should use a UUCP-style lock on the serial device
# to ensure exclusive access to the device.
lock
# Use the modem control lines. On Ultrix, this option implies hardware
# flow control, as for the crtscts option. (This option is not fully
# implemented.)
modem
# Set the MRU [Maximum Receive Unit] value to <n> for negotiation. pppd
# will ask the peer to send packets of no more than <n> bytes. The
# minimum MRU value is 128. The default MRU value is 1500. A value of
# 296 is recommended for slow links (40 bytes for TCP/IP header + 256
# bytes of data).
#mru 542
# Set the interface netmask to <n>, a 32 bit netmask in "decimal dot"
# notation (e.g. 255.255.255.0).
netmask 255.255.255.0
# Disables the default behaviour when no local IP address is specified,
# which is to determine (if possible) the local IP address from the
# hostname. With this option, the peer will have to supply the local IP
# address during IPCP negotiation (unless it specified explicitly on the
# command line or in an options file).
# noipdefault
# Enables the "passive" option in the LCP. With this option, pppd will
# attempt to initiate a connection; if no reply is received from the
# peer, pppd will then just wait passively for a valid LCP packet from
# the peer (instead of exiting, as it does without this option).
#passive
# With this option, pppd will not transmit LCP packets to initiate a
# connection until a valid LCP packet is received from the peer (as for
# the "passive" option with old versions of pppd).
#silent
# Don't request or allow negotiation of any options for LCP and IPCP
# (use default values).
#-all
# Disable Address/Control compression negotiation (use default, i.e.
# address/control field disabled).
#-ac
# Disable asyncmap negotiation (use the default asyncmap, i.e. escape
# all control characters).
#-am
# Don't fork to become a background process (otherwise pppd will do so
# if a serial device is specified).
#-detach
# Disable IP address negotiation (with this option, the remote IP
# address must be specified with an option on the command line or in an
# options file).
#-ip
# Disable magic number negotiation. With this option, pppd cannot
# detect a looped-back line.
#-mn
# Disable MRU [Maximum Receive Unit] negotiation (use default, i.e.
# 1500).
#-mru
# Disable protocol field compression negotiation (use default, i.e.
# protocol field compression disabled).
#-pc
# Require the peer to authenticate itself using PAP.
#+pap
# Don't agree to authenticate using PAP.
#-pap
# Require the peer to authenticate itself using CHAP [Cryptographic
# Handshake Authentication Protocol] authentication.
#+chap
# Don't agree to authenticate using CHAP.
#-chap
# Disable negotiation of Van Jacobson style IP header compression (use
# default, i.e. no compression).
#-vj
# Increase debugging level (same as -d). If this option is given, pppd
# will log the contents of all control packets sent or received in a
# readable form. The packets are logged through syslog with facility
# daemon and level debug. This information can be directed to a file by
# setting up /etc/syslog.conf appropriately (see syslog.conf(5)). (If
# pppd is compiled with extra debugging enabled, it will log messages
# using facility local2 instead of daemon).
#debug
# Append the domain name <d> to the local host name for authentication
# purposes. For example, if gethostname() returns the name porsche,
# but the fully qualified domain name is porsche.Quotron.COM, you would
# use the domain option to set the domain name to Quotron.COM.
#domain <d>
# Enable debugging code in the kernel-level PPP driver. The argument n
# is a number which is the sum of the following values: 1 to enable
# general debug messages, 2 to request that the contents of received
# packets be printed, and 4 to request that the contents of transmitted
# packets be printed.
#kdebug n
# Set the MTU [Maximum Transmit Unit] value to <n>. Unless the peer
# requests a smaller value via MRU negotiation, pppd will request that
# the kernel networking code send data packets of no more than n bytes
# through the PPP network interface.
#mtu <n>
# Enforce the use of the hostname as the name of the local system for
# authentication purposes (overrides the name option).
#usehostname
# Set the assumed name of the remote system for authentication purposes
# to <n>.
#remotename <n>
# Add an entry to this system's ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system.
proxyarp
# Use the system password database for authenticating the peer using
# PAP. Note: mgetty already provides this option. If this is specified
# then dialin from users using a script under Linux to fire up ppp wont work.
# login
# If this option is given, pppd will send an LCP echo-request frame to
# the peer every n seconds. Under Linux, the echo-request is sent when
# no packets have been received from the peer for n seconds. Normally
# the peer should respond to the echo-request by sending an echo-reply.
# This option can be used with the lcp-echo-failure option to detect
# that the peer is no longer connected.
lcp-echo-interval 30
# If this option is given, pppd will presume the peer to be dead if n
# LCP echo-requests are sent without receiving a valid LCP echo-reply.
# If this happens, pppd will terminate the connection. Use of this
# option requires a non-zero value for the lcp-echo-interval parameter.
# This option can be used to enable pppd to terminate after the physical
# connection has been broken (e.g., the modem has hung up) in
# situations where no hardware modem control lines are available.
#lcp-echo-failure 10
# Set the LCP restart interval (retransmission timeout) to <n> seconds
# (default 3).
#lcp-restart <n>
# Set the maximum number of LCP terminate-request transmissions to <n>
# (default 3).
#lcp-max-terminate <n>
# Set the maximum number of LCP configure-request transmissions to <n>
# (default 10).
#lcp-max-configure <n>
# Set the maximum number of LCP configure-NAKs returned before starting
# to send configure-Rejects instead to <n> (default 10).
#lcp-max-failure <n>
# Set the IPCP restart interval (retransmission timeout) to <n>
# seconds (default 3).
#ipcp-restart <n>
# Set the maximum number of IPCP terminate-request transmissions to <n>
# (default 3).
#ipcp-max-terminate <n>
# Set the maximum number of IPCP configure-request transmissions to <n>
# (default 10).
#ipcp-max-configure <n>
# Set the maximum number of IPCP configure-NAKs returned before starting
# to send configure-Rejects instead to <n> (default 10).
#ipcp-max-failure <n>
# Set the PAP restart interval (retransmission timeout) to <n> seconds
# (default 3).
#pap-restart <n>
# Set the maximum number of PAP authenticate-request transmissions to
# <n> (default 10).
#pap-max-authreq <n>
# Set the CHAP restart interval (retransmission timeout for
# challenges) to <n> seconds (default 3).
#chap-restart <n>
# Set the maximum number of CHAP challenge transmissions to <n>
# (default 10).
#chap-max-challenge
# If this option is given, pppd will rechallenge the peer every <n>
# seconds.
#chap-interval <n>
# With this option, pppd will accept the peer's idea of our local IP
# address, even if the local IP address was specified in an option.
ipcp-accept-local
# With this option, pppd will accept the peer's idea of its (remote) IP
# address, even if the remote IP address was specified in an option.
ipcp-accept-remote
defaultroute
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Great reply; this guy needs a life
Reply-To: [EMAIL PROTECTED]
Date: Thu, 07 Dec 2000 17:16:00 GMT
On Thu, 07 Dec 2000 08:01:40 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>Amen, Julie. Great reply. This guy needs a life. I do both Linux and
>Windblows development and do the best I can with the available tools
>and documentation, without whining.
>
>IMHO, if someone does not like something in life, they have 3 choices:
>1. improve it
>2. politely ask others to explain and/or improve
>3. don't use it
I can't believe you forgot the obvious: 4. start huge flamewars on Usenet
denouncing it as the work of Satan. ;)
------------------------------
From: [EMAIL PROTECTED] (Bart De Schuymer)
Subject: bridging for 2.4.0-testx
Date: Thu, 07 Dec 2000 17:31:31 GMT
Hello,
I have a couple of questions about the bridging code:
Do you know if the bridging firewall is being ported to the new
netfilter architecture?
Does anyone know webpages about the bridge code?
brcfg (source code: bridgex-.30) doesn't seem to work for my linux
kernel version 2.4.0-test8 (have been to lazy to update kernel to
newest version). It gives segmentation faults and 'option not
supported' errors.
I do have the kernel compiled with bridging (and the complete
netfilter).
bART
------------------------------
From: [EMAIL PROTECTED]
Subject: How to access PCI configuration registers
Date: Thu, 07 Dec 2000 17:40:30 GMT
New to PCI programming...
How can I read the SMBus Base register which is a PCI configuration
register (function 3, address 90-93) according to Intel's 82371AB spec?
Thanks
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jerome Corre <[EMAIL PROTECTED]>
Subject: log message from linuxrc script
Date: Thu, 07 Dec 2000 17:54:25 GMT
hi,
I have been playing with two step boot using an initial ramdisk,
when my system boot an initial ramdisk is first loaded into /dev/ram0,
then /dev/ram0 is mounted as root and the linuxrc script is executed.
In the linuxrc script i perform several operations and then if possible
/dev/hda1 is mounted as root, if for some reason /dev/hda1 is not
available the linuxrc script modify /proc/sys/kernel/real-root-dev
and /dev/ram0 is remounted as root and init start.
However I haven't been able to log message from the linuxrc script! I
have tryed using logger, initlog but without success. Only message from
the kernel when it boot and message coming from things which run in the
rc.sysinit and other rc script get logged.
what is going wrong? what else can i try?
--
Jerome Corre
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
