Re: PPPoE w/ nat auto fragmentation hack?

[Matthew Emmerton]

> > I'm happy to announce this problem has finally found its final solution
in
> > ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by
> > default!) corrects the outgoing TCP MSS and solves the problem for good.
> > This functionality is strictly identical to what the tcpmssd port does,
but
> > it's now included in ppp, so no need to run an external program with
divert
> > sockets etc.

I've been watching this thread (since when I used to use DSL & PPPoE I used
to see this problem, although at the time I didn't know what it was) and am
amazed at how everyone's worked together to detect and fix this problem.

Now, I'm not trying to play devil's advocate (although that would make me a
friend of Chucky, right?) but I'm wondering if user-ppp is the right place
to make this change.  Isn't the problem specific to PPPoE?  If that's the
case, then shouldn't it be ng_pppoe that gets updated, so that anything that
uses ng_pppoe will have the option of enabling the 'tcpmssfixup' option?

--
Matthew Emmerton



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: PPPoE w/ nat auto fragmentation hack?

[Matthew Emmerton]

> > Matthew Emmerton wrote:
> Julian Elischer wrote:

> > Now, I'm not trying to play devil's advocate (although that would make
me a
> > friend of Chucky, right?) but I'm wondering if user-ppp is the right
place
> > to make this change.  Isn't the problem specific to PPPoE?  If that's
the
> > case, then shouldn't it be ng_pppoe that gets updated, so that anything
that
> > uses ng_pppoe will have the option of enabling the 'tcpmssfixup' option?
>
> I was wondering this yesterday.. either that or a separate mss-hack node..
but
> it needs to look into the tcp packets which means it would have to decode
> the PPP packets and the IP packets as well as the TCP headers, so I think
> that either we do it in the IP stack (with help from tcp) or ppp is the
right
> place, because it already has access to all the information (for it's
packet
> filters).
>
> We COULD make it a function of libNAT as well of course.. :-)

According to Patrick Bihan-Faou, he suggested this a while ago and it was
shot down in favour of the tcpmssd solution, which was later merged into
user-ppp.

If this problem exists with other protocols, or if the solution can be used
with other protocols (in certain situations), then it would make sense to
have it somewhere central so that we can avoid kludging up each
implementation of each protocol that wants to take advantage of it
(user-ppp, ng_ppp, etc).

With this in mind, it really needs to be a part of the IP stack or libalias,
at least.

Perhaps now that the ppp folk have given us a nice reference implementation,
we can work on integrating it more tightly with the system?

--
Matt Emmerton



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: named in a sand box.

[Matthew Emmerton]

> I have a nomenclature ignorance when it comes to the term sandbox.
>
> When someone says, "named runs in a sandbox on my machine."
>
> Do they mean
>
> a) named runs under an unpriviliged user
> or
> b) named runs in a chrooted environment
> or
> c) both

At one point in time, "sandbox" meant a) as above.

However, with the advent of chroot and the security gains that it provides,
"sandbox" has been re-defined to mean b) in most cases.

Unfortunately, this means that some documentation causes confusion, such as
named-related sources you quoted.

--
Matthew Emmerton



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations ?

[Matthew Emmerton]

> At 10:22 4-2-01 -0800, Julian Elischer wrote:
> >John Telford wrote:
> > >
> > > I'm putting  a 4.2 R firewall in for a ppoe connection. (sympatico)
> > > Is there any workaround I can use so I don't have to reduce the MTU on
all
> > > the internal stations ?
> > > It's a mix of Windows 9x and Macs. And I've found only one utility
capable
> > > of adjusting MTU on Macs.
> > > Can anything be done on the freebsd box as the traffic goes through it
?
> > > Thanks in advance, John.
> > > P.S. the pppoe setup went fine thanks to a page at
www.sympaticousers.org
> > > and some further notes at www.freebsddiary.org
> >
> >
> >ppp now has an option where it will force the negotiated packet size
> >of new tcp sessions going through it down. (i.e it fiddles with the
packets)
> >check the man page.. I THINK it may be in 4.2, if not it's in -Stable
>
> Actually, I have just been playing with this. Userland ppp has the 'set
> mtu' command which will make ppp try and set that MTU at negotiation time.

Isn't the proper command 'set tcpmssfixup'?  Sure, 'set mtu' will allow you
to set the MTU, but 'set tpmssfixup' will ensure that any MTU bashing
(explained very nicely at http://renaud.waldura.com/doc/freebsd-pppoe/) is
properly accounted for..

--
Matt Emmerton



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Adding IP aliases

[Matthew Emmerton]

> Does anyone know of a FAQ or HOWTO for adding IP aliases to a
> FreeBSD box? I can do it under linux and Im just wondering if there are
any
> differences or what-not.

In /etc/rc.conf, add or edit lines like this (I have an 'ed0' network card):

network_interfaces="lo0 ed0"
ifconfig_lo0="inet 127.0.0.1 netmask 255.0.0.0"
ifconfig_ed0="inet 192.168.0.2 netmask 255.255.255.0"
ifconfig_ed0_alias0="inet 192.168.0.10 netmask 255.255.255.255"
ifconfig_ed0_alias1="inet 192.168.0.11 netmask 255.255.255.255"

You need to set the netmask of the aliases to what I have above, otherwise
you won't be able to use the aliased IPs.

If you want to do it from the command line (note that your aliases will be
lost when you reboot unless you do the above), do this:

ifconfig ed0 alias 192.168.0.10 netmask 255.255.255.255

--
Matt Emmerton



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: ipfw simple quesiton

[Matthew Emmerton]

> >is it possible to have natd run on both external interfaces without
> >causing problems?  how would i configure that?
>
> Why would you want to run natd on external 2 interfaces at the same time?

I'm not sure if this is the case, but if the box was multihomed (for
example, DHCP-based DSL and Cable), then you would want NATD running on both
external interfaces.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Quick question about IP aliasing

[Matthew Emmerton]

> > do 'netmask 255.255.255.255' instead or 'netmask 0x' since this
is
> > an alias... for some reason otherwise services may not bind to the ip
> > correctly
>
> Why would this be?  The two are numerically equivalent.

Yes, but you're missing the point.

The point is that you need to use a netmask of 255.255.255.255 for aliased
IPs on FreeBSD, regardless of the alias of the primary (non-alias) IP.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Quick question about IP aliasing

[Matthew Emmerton]

> > On Tue, Feb 27, 2001 at 07:16:14AM +0100, Rogier R. Mulhuijzen wrote:
> > >
> > > > [ Matt Emmerton wrote: ]
> > > >The point is that you need to use a netmask of 255.255.255.255 for
aliased
> > > >IPs on FreeBSD, regardless of the alias of the primary (non-alias)
IP.
>
> no this is incorrect. you just have to make sure that the aliased
> IP&mask do not generate info which is already in the routing table.
> E.g. if your primary addr is 1.2.3.4/24 , an alias of 1.2.3.5/24 will
> give a warning, but an alias of 1.2.4.4/24 will not, and most likely even
> 1.2.3.5/25 will not.

I'm just reiterating what I was told 1.5 years ago when I complained that
the following setup wouldn't work:

Primary IP:  192.168.0.1/255.255.255.0
Aliased IP:  192.168.0.10/255.255.255.0

With this setup, I could not ping, traceroute or connect to the aliased IP.
In order to make the aliased IP functional, I had to use a netmask of
255.255.255.255 -- a fact which I find totally confusing and
counter-intuitive, but one that seems to work.

> > > Everybody is saying use 255.255.255.255 for an alias. Noone is giving
> > > reasons why.

Exactly.  I never got a good answer to this when I first stumbled upon it,
and I still haven't.  All I know is that this is the way it needs to be done
in order for things to work properly.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Quick question about IP aliasing

[Matthew Emmerton]

> Josef Karthauser wrote:
> >
> > On Tue, Feb 27, 2001 at 07:16:14AM +0100, Rogier R. Mulhuijzen wrote:
> > >
> > > >The point is that you need to use a netmask of 255.255.255.255 for
aliased
> > > >IPs on FreeBSD, regardless of the alias of the primary (non-alias)
IP.
> > >
> > > Everybody is saying use 255.255.255.255 for an alias. Noone is giving
> > > reasons why.
> >
> > I don't understand this either.  To my mind it's a bug if it doesn't
> > work with the full netmask for an IP alias address.
>
> Because if you don't, it won't work.  ifconfig(8) may not be telling the
> entire truth here:
>
>  alias   Establish an additional network address for this interface.
This
>  is sometimes useful when changing network numbers, and one
wishes
>  to accept packets addressed to the old interface.  If the
address
>  is on the same subnet as the first network address for this
in-
>  terface, a netmask of 0x has to be specified.
>
> Somebody should look to see if the man page is true, or if you have to use
> a netmask of 0x for all aliases.

I just had a short off-line conversation with Luigi Rizzo about this, and
the manpage is true. (You must use a netmask of 0x for aliases on
the same subnet as the primary IP, otherwise you use the appropriate netmask
for the alias IP.)

Since the more intuitive method is to use the 'appropriate' netmask all the
time (and is what AIX and SCO do), I'm looking into seeing what it would
take to add this functionality to FreeBSD.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Quick question about IP aliasing

[Matthew Emmerton]

> > > > > Everybody is saying use 255.255.255.255 for an alias. Noone is
giving
> > > > > reasons why.
> >
> >Exactly.  I never got a good answer to this when I first stumbled upon
it,
> >and I still haven't.  All I know is that this is the way it needs to be
done
> >in order for things to work properly.
>
> Ok, I meant everyone is saying use 255.255.255.255 for an alias even if
> it's on a different subnet. I've been preaching to use the real subnet
when
> the alias is on a different subnet from the start of this thread =)

That's partly my fault, as I wasn't aware that you are to use the real
subnet when your aliased IP is on a different subnet.  At least I'm
straightened out now :)

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: dhclient not setting IP ...

[Matthew Emmerton]

> I'm connected through cable to the 'Net, and the provider I go
> through, it appears, somehow has it setup that if I change nics, I hvae a
> bugger of a time re-acquiring a lease ...

I presume dhclient is what you use to get your IP address.

I've seen ISPs that record the MAC address of the interface, and won't give
out addresses to any other MAC address but the original one.  They'll expire
that MAC eventually, but perhaps not for 24 hours or a week.

I've also seen ISPs that require the 'host-name' parameter to be set in
dhclient.conf, and if not, won't return any DHCP queries at all.  I doubt
that this is your problem since you're seeing the problem on more than one
machine.

What does dhclient log into /var/log/syslog?  If you see a lot of
DHCPDISCOVER / DHCPREQUEST lines but no DHCPACKs, then your ISP's DHCP
server isn't a) getting your requests or b) responding to them.  In the case
of b), it may be because your MAC address or host-name.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: D-Link problem

[Matthew Emmerton]

> I'm setting up a system (200MHz) with 4.2-RELEASE, and the network card
that
> I have to go in it is a D-Link DFE-538TX/R PCI card, based on the RealTek
> 8139 chipset.

[ snip ]

> pci0:  (vendor=0x1186, dev=0x1300) at 11.0 irq 11
>
> I know the unknown card here is the network card, since the vendor ID
> matches the one shown by the BIOS as "network controller" during system
> boot.  There are no other devices conflicting with IRQ 10 or 11.

[ snip ]

> I added the appropriate
> defines and extended the array of cards defined in if_rlreg.h, updated
> if_rl.c to match, and rebuilt the kernel.  This now recognizes the card
> during the boot sequence, but then crashes like so:

[ snip ]

Well, you're on the right track.  More than likely the D-Link card has some
flags that aren't being properly set during the driver init.

In the meantime, it would be best if you built a debug kernel and enabled
crashdumps.  This would give you (and us) more details on where (and why)
this thing is crashing.

Section 23 of the FreeBSD Handbook
(http://www.freebsd.org/handbook/kerneldebug.html) has details of how to do
this.  (Be sure to set dumpdev to your swap slice, and make sure that
sizeof(swap) > sizeof(RAM)).

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: D-Link problem

[Matthew Emmerton]

> Okay, I've managed to get the debug kernel built and save the core file.
> I'll include the output of some basic debugging below.  If there's
anything
> else that would be helpful, let me know.  The D-Link driver disk includes
C
> source for a Linux driver, so when the problem gets narrowed down, I or
> someone more familiar with the code might be able to use this to determine
> the correct settings.
>
> First, though, I should have included this before, but I didn't notice it
> until much later.  Here's an excerpt from the boot messages that gets
shown
> before the crash.  During a GENERIC boot:
>
> rl0:  port 0xd800-0xd8ff
>   mem 0xe580-0xe58000ff irq 11 at device 11.0 on pci0
> rl0: Ethernet address xx:xx:xx:xx:xx:xx
> miibus0:  on rl0
> rlphy0:  on miibus0
> rlphy0: no media present

I'd change the device naming in pci/if_rl.c to identify the card vendor &
model (D-Link 538TX/R, in the style of the Accton MPX driver) rather than
the card chipset (which would be used for a generic card).

> It then proceeds through the normal boot sequence to the crash.  Here's
the
> gdb log I threatened above.  Warning: it's long.

[snip] Sorry 'bout that.  I was working on the assumption that the driver
was working properly, and was just dying during userland init (ifconfig).
The "rlphy0: no media present" line tells us that the driver isn't 100%
healthy, at least with this card.

It would be interesting to see what the result of the PHY_READ call is (just
before the 'no media present' printf line).  It could be that the D-Link
card is encoding media types differently (which means that BMSR_MEDIAMASK
needs updating), or is simply really telling us nothing.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: D-Link problem

[Matthew Emmerton]

> >[snip] Sorry 'bout that.  I was working on the assumption that the driver
> >was working properly, and was just dying during userland init (ifconfig).
> >The "rlphy0: no media present" line tells us that the driver isn't 100%
> >healthy, at least with this card.
>
> Not a problem.  Good learning exercise for me.

Most definitely.  (I did my first panic / kernel debug exercise last month.)

> The PHY_READ call is returning 6, which is BSMR_LINK | BSMR_JABBER.  I
> checked capmask, and it's 0x, so that's okay.  Looks like the
> "nothing" gues is accurate.  I tried hard coding the capabilities
> (overriding the return value) to those listed in the manual (10 and 100,
> full and half, and autonegotiate), and it still kernel panics the same
way,
> so I would guess that there are two problems here, not just one.

Are you sure the card is using the 8139 chipset?  The 8139 can provide PHY
information via the status register.  Since we're obviously not getting any
such data, I'm wondering if this card is based on something else.  I've seen
some chatter on some Linux lists that would indicate that there are two
version of the DFE538 - one that works with the RealTek 8129/8139 driver
(rl0), and one that works with the NE2000 driver (ed0).  Also interesting --
the pciconf -l output from your machine indicates 'rev=0x10' -- this may be
the discriminator between whether the card is rl0 or ed0 based.

If you want to try out the ed driver, you'll have to hack dev/ed/if_ed_pci.c
and put the device/vendor codes in there.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: D-Link problem

[Matthew Emmerton]

> >Are you sure the card is using the 8139 chipset?  The 8139 can provide
PHY
> >information via the status register.  Since we're obviously not getting
any
> >such data, I'm wondering if this card is based on something else.
>
> I'm pretty sure it is.  The Linux driver source file is called
"rtl8139.c",
> so that's a good hint.  Is there a way to tell them apart by looking at
the
> board?  Mine says "DFE-538TX Rev. D1", and the only chip on the board says
> "DL10038C".

And according to the picture of a Rev A1 card, the chip's number hasn't
changed.  Puzzling.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Slow netstat -r printout

[Matthew Emmerton]

> It's taking so long because it's trying to do a DNS resolution of every IP
> address that it prints. My guess is that @Home uses some non-registered
> RFC1918 address space for its clients, so those addresses will never
> resolve, and will take forever not doing so. The -n flag disables DNS
> resolution, which is why it's so much faster.

Do 'netstat -rn' once and record the RFC1918 addresses that @Home is using.
Then add the appropriate entries to /etc/hosts.  After that, you can do
'netstat -r' and the RFC1918 addresses will be resolved from /etc/hosts,
which is much, much faster.

--
Matt Emmerton




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: VPN tunnel with DHCP ...

[Matthew Emmerton]

> Hi,
>
> about my SOHO router project, I came accross a tough problem, may
> be I overlook that there is a solution already? The VPN gateway
> at the small office / home office (SOHO) has an IPsec tunnel
> connecting it to its headquarter:
>
> setkey -c  <   spdadd ${sohonet} ${homenet} -P out ipsec
>  esp/tunnel/${sohoip}-${homeip}/require;
>   spdadd ${homenet} ${sohonet} -P in ipsec
>  esp/tunnel/${homeip}-${sohoip}/require;
> END
>
> now, the problem is that the ${sohoip} is dynamically assigned
> with DHCP. How can the gateway at the headquarter know that
> ${sohoip} address?

I had a similar situation which I had to work with a while ago, although I
used ssh tunnels instead of IPSec.  I'm not sure if my method will work, but
it's worth an try.

Here's what I did:
1) Set the headquarters machine up with static IP and DNS.
2) Configure headquarters machine to allow PPP over TCP
3) Have remote hosts (with dynamic addresses) connect to headquarters
machine (static address) using PPP over TCP.  The endpoints of this PPP
connection use "private" IPs, say 10.x.x.x or 192.168.x.x.  Note that once
the connection is established, the addresses of both endpoints are known.
4) Create SSH tunnels in each direction
5) Forward all traffic over the SSH tunnel

In your case, you could probably use IPsec over the PPP connection instead
of SSH.

--
matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: VPN tunnel with DHCP ...

[Matthew Emmerton]

> > > Hi,
> > >
> > > about my SOHO router project, I came accross a tough problem, may
> > > be I overlook that there is a solution already? The VPN gateway
> > > at the small office / home office (SOHO) has an IPsec tunnel
> > > connecting it to its headquarter:
> > >
> > > setkey -c  < > >   spdadd ${sohonet} ${homenet} -P out ipsec
> > >  esp/tunnel/${sohoip}-${homeip}/require;
> > >   spdadd ${homenet} ${sohonet} -P in ipsec
> > >  esp/tunnel/${homeip}-${sohoip}/require;
> > > END
> > >
> > > now, the problem is that the ${sohoip} is dynamically assigned
> > > with DHCP. How can the gateway at the headquarter know that
> > > ${sohoip} address?
> >
> > I had a similar situation which I had to work with a while ago, although
I
> > used ssh tunnels instead of IPSec.  I'm not sure if my method will work,
but
> > it's worth an try.
> >
> > Here's what I did:
> > 1) Set the headquarters machine up with static IP and DNS.
> > 2) Configure headquarters machine to allow PPP over TCP
> > 3) Have remote hosts (with dynamic addresses) connect to headquarters
> > machine (static address) using PPP over TCP.  The endpoints of this PPP
> > connection use "private" IPs, say 10.x.x.x or 192.168.x.x.  Note that
once
> > the connection is established, the addresses of both endpoints are
known.
> > 4) Create SSH tunnels in each direction
> > 5) Forward all traffic over the SSH tunnel
> >
> > In your case, you could probably use IPsec over the PPP connection
instead
> > of SSH.
>
> This is a good solution because (as you say) ppp will negotiate an
> address with the other side and the setkey stuff can be done in
> ppp.linkup.
>
> Of course it's a bad solution because of the per-packet overhead and
> the two layers of tcp you'll get with any tcp connection through your
> tunnel (I really must write a udp mux program for ppp).

The plan was designed for 4 remote sites using 1Mbit DSL terminating at an
HQ with 2.2Mbit DSL, all for running a character-based app and pushing email
out to these remote sites of ~5 users.  With this in mind, the overhead
wasn't a concern.

> You need to be careful however.  The ppp.linkup on the side with
> the static IP number should blow away any other ppp sessions that are
> active with the peer (it's ok to do this in ppp.linkup as you've
> authenticated the client at that point).  The problem is that ppp
> will never bring the link fully up if there's a stale connection via
> the previous dynamic IP if the negotiated IP numbers are the same.
>
> So make sure that the side with the static IP has something like this
> in it's config:
>
>   set ifaddr x.x.x.x a.a.a.a-b.b.b.b
>
> where x.x.x.x doesn't matter much (it's what the other end will route
> packets to) and a.a.a.a-b.b.b.b is a range of IP numbers that can be
> used by the side with the dynamic IP (for the top-side of the tunnel).

Ahh, yes, I can see how this would have been a problem.  I think I got
around this by having the "server" accepting PPP over TCP connection on 4
different ports, with each remote site assigned a different port, hence
keeping everyone in line.

In addition, I must say that I never did implement this although I was
really looking forward to it.  (My boss felt it neccessary to describe the
technical intricacies of it to the client, who just got confused and dropped
the project.)  However, this was the defining moment in time where I truly
began to appreciate the cool stuff that FreeBSD can do for me.

Now, back to Gunther's request - could you do IPSec over PPP over TCP?

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: no free() after malloc() in arp (src/usr.sbin/arp/arp.c)

[Matthew Emmerton]

> i don't see a security issue in this, just want to ask if this is ok (or
> maybe unwanted?):
>
> in src/usr.sbin/arp/arp.c in function search() (starts line ~429) i see
> this (line ~447):
>
> if ((buf = malloc(needed)) == NULL)
>
> this allocated memory isn't free'd later in this function. so if arp uses
> this function over and over again, memory fills up (not much, but it
does).

This has been reported with a fix in PR bin/27001.
http://www.freebsd.org/cgi/query-pr.cgi?pr=27001

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: IP alias problem /w 2 different subnets.

[Matthew Emmerton]

> Does anyone see any problem with the below rc.conf network info? Because
the
> aliases arent working.. and I have verified that the 209.190.xxx.xxx ips
are
> being routed to the 209.51.xxx.xxx IP, anyone have any idea on this?
>
> network_interfaces="fxp0 lo0"
> ifconfig_fxp0="inet 209.51.xxx.xxx  netmask 255.255.255.0"
> ifconfig_fxp0_alias0="inet 209.190.xxx.xxx netmask 255.255.255.255"
> ifconfig_fxp0_alias1="inet 209.190.xxx.xxx netmask 255.255.255.255"
[ snip ]

The rule for aliases (as outlined in 'man ifconfig') is:
- if the aliased IP is on the same subnet as the primary IP, use the
255.255.255.255 netmask
- if the aliased IP is on a different subnet than the primary IP, use the
appropriate netmask for the aliased IP

So if your 209.190.xxx.xxx IPs are on a /24 network, then you should be
using the 255.255.255.0 netmask.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Netgraph/fxp/pppoe causing system panic in 4.3 stable.

[Matthew Emmerton]

I'm not sure if it's just fxp0 -- a few weeks ago a few people reported this
very same problem with PPPoE for cards other than fxp0.
Adding an ifconfig_xxx="up" to /etc/rc.conf (as suggested by an article on
daemonnews or freebsddiary) "fixed" the problems for the people that I heard
about -- but you're right that it isn't the best solution.

The problem is this:  if a card is down, it's because a) it's never been
configured or b) it was downed manually.  In the former case, we want PPPoE
to initialize and start using the card (since you'd never have to initialize
the NIC being used for PPPoE.)  However, in case b), the driver should just
ignore the data.

How can we differentiate between case a) and case b)?  I could see some
admins getting pretty peeved if they 'ifconfig down fxp0' and then a few
seconds later, PPPoE brings the interface back up to send data. (Of course,
it would be better to kill the PPPoE daemon first before doing that, but...)

> PPPoE now brings the interface IFF_UP before using it, but this isn't
> the right solution (someone could manually down it again).
>
> fxp should just drop data if it's not up.
>
> > I have a reproducible kernel panic in 4.3 stable caused (sort of) by
> > netgraph, or maybe by fxp0 in conjunction with pppoe. It is caused by
> > setting up and attempting to open a pppoe connection over an fxp
> > interface, due to fxp_start being called before fxp device has been
> > opened. (This only occurs if the fxp interface has not been configured
> > in any way since since boot.)
> >
> > Maybe if ethernet if has not been opened, and is down, it should be
brought up
> > by opening it for pppoe similar to ifconfig bringing it up when an ip
> > address is assigned ?
> >
> > Causing the fault is as simple as running user land ppp, configuring
'set line
> > pppoe:fxp0' and then trying to open the link.
> >
> > Backtrace is as follows.
> > #0  0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083
> > #1  0xc01e4de4 in ether_output_frame (ifp=0xc0cbea00, m=0xc09d3d00) at
../../net/if_ethersubr.c:399
> > #2  0xc01fac2c in ng_ether_rcv_lower (node=0xc0cd3100, m=0xc09d3d00,
meta=0x0) at ../../netgraph/ng_ether.c:629
> > #3  0xc01fab55 in ng_ether_rcvdata (hook=0xc0e0bf40, m=0xc09d3d00,
meta=0x0) at ../../netgraph/ng_ether.c:595
> > #4  0xc01f8401 in ng_send_data (hook=0xc0e0bfc0, m=0xc09d3d00, meta=0x0)
at ../../netgraph/ng_base.c:1648
> > #5  0xc01fc6e9 in sendpacket (sp=0xc0e0f840) at
../../netgraph/ng_pppoe.c:1451
> > #6  0xc01fb99e in pppoe_start (sp=0xc0e0f840) at
../../netgraph/ng_pppoe.c:754
> > #7  0xc01fb824 in ng_pppoe_rcvmsg (node=0xc0da8ac0, msg=0xc0e0f800,
retaddr=0xc0e0bf00 "[7]:", rptr=0xc643fe28)
> > at ../../netgraph/ng_pppoe.c:660
> > #8  0xc01f7925 in ng_send_msg (here=0xc0d607c0, msg=0xc0e0f800,
address=0xc0cd4650 ".:tun0", rptr=0xc643fe28)
> > at ../../netgraph/ng_base.c:1180
> > #9  0xc01fc954 in ngc_send (so=0xc5d5dc00, flags=0, m=0xc09e1f00,
addr=0xc0cd4620, control=0x0, p=0xc5f44700)
> > at ../../netgraph/ng_socket.c:242
> > #10 0xc01bffcb in sosend (so=0xc5d5dc00, addr=0xc0cd4620,
uio=0xc643fed0, top=0xc09e1f00, control=0x0, flags=0, p=0xc5f44700)
> > at ../../kern/uipc_socket.c:611
> > #11 0xc01c377f in sendit (p=0xc5f44700, s=2, mp=0xc643ff10, flags=0) at
../../kern/uipc_syscalls.c:583
> > #12 0xc01c3882 in sendto (p=0xc5f44700, uap=0xc643ff80) at
../../kern/uipc_syscalls.c:636
> > #13 0xc03340ad in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077941491, tf_esi = -1077941498, tf_ebp = -1077940984,
> >   tf_isp = -968622124, tf_ebx = 672834760, tf_edx = -1077941500,
tf_ecx = -1077941500, tf_eax = 133, tf_trapno = 7, tf_err = 2,
> >   tf_eip = 673075808, tf_cs = 31, tf_eflags = 518, tf_esp
= -1077941588, tf_ss = 47}) at ../../i386/i386/trap.c:1150
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083
> > 1083txp = sc->cbl_last->next;
> >
> > (kgdb) print sc
> > $1 = (struct fxp_softc *) 0xc0cbea00
> > (kgdb) print sc->cbl_last
> > $2 = (struct fxp_cb_tx *) 0x0
>
> --
> Brian <[EMAIL PROTECTED]>
>      
> Don't _EVER_ lose your sense of humour !
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Netgraph/fxp/pppoe causing system panic in 4.3 stable.

[Matthew Emmerton]

However, in 3.4, netgraph + pppoe didn't require "ifconfig iface up" in
rc.conf in order to use PPPoE, but that requirement has been in 4.x from the
beginning.  The big question is, why did this behaviour change? (Insert POLA
argument here.)

I can't really see why we shoudl be forcing users to "ifconfig iface up"
their ethernet NIC in rc.conf, when it's really abstracted away by PPPoE --
netgraph should look after bringing the interface up, and perhaps complain
loudly if someone should down it while it's being used.  (I'm thinking that
the control of the interface should lie under netgraph and it's tools, not
standard userland tools like ifconfig, for "abstracted" cases like this.)

> I guess the key question is whether PPPoE should use the interface if
> it's not IFF_UP.
>
> If it shouldn't, the interface should drop the data on the floor.
>
> If it should, the interface should just deal with it.
>
> I'd suggest that we should fix the guilty interfaces and
> automatically ``ifconfig iface up'' from the rc script.  ppp
> shouldn't be bringing the interface up itself.
>
> > I'm not sure if it's just fxp0 -- a few weeks ago a few people reported
this
> > very same problem with PPPoE for cards other than fxp0.
> > Adding an ifconfig_xxx="up" to /etc/rc.conf (as suggested by an article
on
> > daemonnews or freebsddiary) "fixed" the problems for the people that I
heard
> > about -- but you're right that it isn't the best solution.
> >
> > The problem is this:  if a card is down, it's because a) it's never been
> > configured or b) it was downed manually.  In the former case, we want
PPPoE
> > to initialize and start using the card (since you'd never have to
initialize
> > the NIC being used for PPPoE.)  However, in case b), the driver should
just
> > ignore the data.
> >
> > How can we differentiate between case a) and case b)?  I could see some
> > admins getting pretty peeved if they 'ifconfig down fxp0' and then a few
> > seconds later, PPPoE brings the interface back up to send data. (Of
course,
> > it would be better to kill the PPPoE daemon first before doing that,
but...)
> >
> > > PPPoE now brings the interface IFF_UP before using it, but this isn't
> > > the right solution (someone could manually down it again).
> > >
> > > fxp should just drop data if it's not up.
>
> --
> Brian <[EMAIL PROTECTED]>
>      
> Don't _EVER_ lose your sense of humour !
>
>
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Help with IPSec VPN

[Matthew Emmerton]

Hi all,

I've been trying to get an IPSec tunneling VPN between two boxes working
without much success.  I've read the FAQs and HOWTOs on www.freebsd.org,
www.freebsddiary.org, www.daemonnews.org and www.kame.net and they all have
helped me get closer to where I want to be, but I'm still missing something.

The exact problem that I'm running into is that once I've got everything
configured (all details below), when I try and ping the other end of the
tunnel, nothing happens.  I get this from 'netstat -p ipsec', with every
other ipsec counter showing a value of 0.

8 outbound packets with no SA available

Both boxes are running RELENG_4_3 (security release), and have 'options
IPSEC' and 'options IPSEC_ESP' in the kernel.

Box A is 192.168.0.2/24, Box B is 192.168.0.3/24.

Here's what I'm doing on box A:

gabby# gifconfig gif0 192.168.0.2 192.168.0.3
gabby# ifconfig gif0 inet 10.0.2.1 10.0.3.1 netmask 255.255.255.0
gabby# setkey -F
gabby# setkey -FP
gabby# setkey -c << EOF
add 10.0.2.1 10.0.3.1 esp 1000 -E 3des-cbc "goofgoofgoofgoofgoofgoof";
add 10.0.3.1 10.0.2.1 esp 1001 -E 3des-cbc "foolfoolfoolfoolfoolfool";
spdadd 10.0.2.0/24 10.0.3.0/24 any -P out ipsec
esp/tunnel/192.168.0.2-192.168.0.3/require;
spdadd 10.0.3.0/24 10.0.2.0/24 any -P in ipsec
esp/tunnel/192.168.0.3-192.168.0.2/require;
EOF
gabby# route add -net 10.0.3.0/24 10.0.3.1
gabby#

I'm doing the exact same thing on Box B, except that all the IP pairs are
reversed, with the exception of the 'add' lines for setkey (as outlined in
the KAME IpSec FAQ, VPN tunnel section.) and the route statement.

Here's output from gifconfig, ifconfig, netstat, and setkey (slightly
trimmed):
gabby# gifconfig -a gif0
gif0: flags=8011 mtu 1280
inet6 fe80::200:c0ff:fef2:7c40%gif0 --> ::  prefixlen 64
inet 10.0.2.1 --> 10.0.3.1 netmask 0xff00
physical address inet 192.168.0.2 --> 192.168.0.3

gabby# ifconfig gif0
gif0: flags=8011 mtu 1280
inet6 fe80::200:c0ff:fef2:7c40%gif0 --> :: prefixlen 64 scopeid 0x4
inet 10.0.2.1 --> 10.0.3.1 netmask 0xff00

gabby# netstat -rn -f inet
DestinationGatewayFlags Refs Use Netif
Expire
default192.168.0.1UGSc10  ed0
10.0.3/24  10.0.3.1   UGSc00 gif0
10.0.3.1   10.0.2.1   UH  18 gif0
127.0.0.1  127.0.0.1  UH  1   92  lo0
192.168link#1 UC  00  ed0 =>

gabby# setkey -D
10.0.3.1 10.0.2.1
esp mode=any spi=1001(0x03e9) reqid=0(0x)
E: 3des-cbc  666f6f6c 666f6f6c 666f6f6c 666f6f6c 666f6f6c 666f6f6c
replay=0 flags=0x0040 state=mature seq=1 pid=403
created: Aug 31 08:39:59 2001   current: Aug 31 09:11:49 2001
diff: 1910(s)   hard: 0(s)  soft: 0(s)
last:   hard: 0(s)  soft: 0(s)
current: 0(bytes)   hard: 0(bytes)  soft: 0(bytes)
allocated: 0hard: 0 soft: 0
refcnt=1
10.0.2.1 10.0.3.1
esp mode=any spi=1000(0x03e8) reqid=0(0x)
E: 3des-cbc  676f6f66 676f6f66 676f6f66 676f6f66 676f6f66 676f6f66
replay=0 flags=0x0040 state=mature seq=0 pid=403
created: Aug 31 08:39:59 2001   current: Aug 31 09:11:49 2001
diff: 1910(s)   hard: 0(s)  soft: 0(s)
last:   hard: 0(s)  soft: 0(s)
current: 0(bytes)   hard: 0(bytes)  soft: 0(bytes)
allocated: 0hard: 0 soft: 0
refcnt=1

gabby# setkey -DP
10.0.3.0/24[any] 10.0.2.0/24[any] any
in ipsec
esp/tunnel/192.168.0.3-192.168.0.2/require
spid=4 seq=1 pid=404
refcnt=1
10.0.2.0/24[any] 10.0.3.0/24[any] any
out ipsec
esp/tunnel/192.168.0.2-192.168.0.3/require
spid=3 seq=0 pid=404
refcnt=1

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Possibly Bug Report with Kernel ep (3com 5xx ISA and others) driver

[Matthew Emmerton]

> >> The machine has 2 interfaces (obviously ep0 and ep1), and
> >> after about 24 hours uptime, ep1 was somehow broken:
> >>
> >> If trying to ping: sendto: no bufferspace available
> >>
> >> ifconfig ep1 down, ifconfig ep1 up was a work-around, but no
> >> solution...
> >>
> >> Netstat showed nothing 'extraordinary' like high ammount of
> >> collissions, late collisions, fragmentations, carrier losses
> >> even the net work load was almost a little above nothing.
>
> >All of these are typical of media problems - bad cables or
> >ports on your hub or switch.

> I can exclude this:
>  - The statistics do not show any 'loss of carrier' (mentioned
> above)
>  - On the same hub's, there are some highly available financial
> applications and web-servers. If there would be that sort of
> problem, I'd surely noticed.
>  - For some other reason, we changed the hub and cabeling, and
> the problem still exists...

Ack!  My error - I didn't notice the "nothing".

> >> I remember to have the same problem with another box running
> 3.3
> >> generic (other hardware...) - so I am wondering if the driver
> >> might be somehow broken.
> >
> >But if it was a driver problem, the problem would show up on
> >both interfaces, right?
>
> Yes, and inbetween I can confirm: The problem occurs on both
> interfaces; the chance that the problem occurs is slightly
> higher on the interface with the higher network load.
>
> To sum up: As the very same problem occurs with pretty different
> hardware, I really think there's something wrong with the
> cooperation of the ep-driver and 3com 509 - maybe the driver,
> maybe some design error on the network cards...
>
> So if sb says: 'No probs with ep driver and ne2000 cards', then
> I think we have to ask 3com... ;)

Aren't the 509s ISA-based?  My thought would be just to replace them with a
newer, more stable NIC.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

ping gif0

[Matthew Emmerton]

I've got a question for all of you net hackers.

When I configure a gif interface, why can't I ping the local endpoint on the
inside of the tunnel?  I've just been through hell and back trying to get
some IPSec tunnels created (they're working now, thanks to all those who
helped me out), and this was one of my big stumbling blocks -- since I
couldn't ping the local or remote endpoint of the gif tunnel, I spent much
time chasing down problems with gif when it wasn't a problem at all.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Forward: Re: ping gif0

[Matthew Emmerton]

On Mon, 10 Sep 2001, Brian Somers wrote:

> > > On Mon, 10 Sep 2001 11:54:49 +0100, 
> > > Brian Somers <[EMAIL PROTECTED]> said:
> > 
> > > The local endpoint can't be pinged unless you've got a route for 
> > > it... that's just the way the routing code works.
> > 
> > > You can ping the local address for an Ethernet interface, but that's 
> > > just because the hardware returns such packets.
> > 
> > > Adding a loopback route or address alias is the way to handle this.
> > 
> > Correct, but in this case, pinging the other end of the link also
> > failed:
> > 
> > gif0: flags=8011 mtu 1280
> > inet 10.0.2.130 --> 10.0.2.2 netmask 0x 
> > physical address inet 209.167.75.123 --> 209.167.75.124
> > 
> > waterloo.heers.on.ca# ping 10.0.2.2
> > PING 10.0.2.2 (10.0.2.2): 56 data bytes
> > ^C
> > --- 10.0.2.2 ping statistics ---
> > 15 packets transmitted, 0 packets received, 100% packet loss
> > 
> > I don't get the reason for this part.  This is perhaps due to some
> > IPsec issues?  netstat gave us an interesting result:
> > 
> >34 inbound packets violated process security policy
> 
> This rings bells.  I have been having difficulties with an IPSEC over 
> gif setup recently, but they went away with the latest racoon update 
> in the ports collection.  They *may* have appeared with the previous 
> racoon update - I'm not sure.  The symptoms were bizarre.

However, I'm not using racoon.  Static keys, using '-E simple ""' as the
encryption algorithm. (This helps me figure out whats going on with
tcpdump and ethereal much more easily.)

LAN1 machines can talk to LAN2 machines and vice versa with absolutely no
problems.  However, the LAN1 gateway can't talk to the LAN2 gateway and
vice versa.  As was pointed out, I need to set up some localhost routes in
order to ping the local end of the tunnel.

What remains is a) why can't I ping the remote end of the tunnel without
receiving these "violated process security policy" messages, and b) why
can't I connect to the remote end of the tunnel.  The latter breaks
DNS forwarding / HTTP proxy / sendmail forwarding, and is becoming a real
problem.

--
Matt Emmerton




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Forward: Re: ping gif0

[Matthew Emmerton]

On Mon, 10 Sep 2001, Brian Somers wrote:

> > On Mon, 10 Sep 2001, Brian Somers wrote:
> > 
> > > > > On Mon, 10 Sep 2001 11:54:49 +0100, 
> > > > > Brian Somers <[EMAIL PROTECTED]> said:
> > > > 
> > > > > The local endpoint can't be pinged unless you've got a route for 
> > > > > it... that's just the way the routing code works.
> > > > 
> > > > > You can ping the local address for an Ethernet interface, but that's 
> > > > > just because the hardware returns such packets.
> > > > 
> > > > > Adding a loopback route or address alias is the way to handle this.
> > > > 
> > > > Correct, but in this case, pinging the other end of the link also
> > > > failed:
> > > > 
> > > > gif0: flags=8011 mtu 1280
> > > > inet 10.0.2.130 --> 10.0.2.2 netmask 0x 
> > > > physical address inet 209.167.75.123 --> 209.167.75.124
> > > > 
> > > > waterloo.heers.on.ca# ping 10.0.2.2
> > > > PING 10.0.2.2 (10.0.2.2): 56 data bytes
> > > > ^C
> > > > --- 10.0.2.2 ping statistics ---
> > > > 15 packets transmitted, 0 packets received, 100% packet loss
> > > > 
> > > > I don't get the reason for this part.  This is perhaps due to some
> > > > IPsec issues?  netstat gave us an interesting result:
> > > > 
> > > >34 inbound packets violated process security policy
> > > 
> > > This rings bells.  I have been having difficulties with an IPSEC over 
> > > gif setup recently, but they went away with the latest racoon update 
> > > in the ports collection.  They *may* have appeared with the previous 
> > > racoon update - I'm not sure.  The symptoms were bizarre.
> > 
> > However, I'm not using racoon.  Static keys, using '-E simple ""' as the
> > encryption algorithm. (This helps me figure out whats going on with
> > tcpdump and ethereal much more easily.)
> > 
> > LAN1 machines can talk to LAN2 machines and vice versa with absolutely no
> > problems.  However, the LAN1 gateway can't talk to the LAN2 gateway and
> > vice versa.  As was pointed out, I need to set up some localhost routes in
> > order to ping the local end of the tunnel.
> > 
> > What remains is a) why can't I ping the remote end of the tunnel without
> > receiving these "violated process security policy" messages, and b) why
> > can't I connect to the remote end of the tunnel.  The latter breaks
> > DNS forwarding / HTTP proxy / sendmail forwarding, and is becoming a real
> > problem.
> 
> What does your security policy say ?  I have this on the LAN1 gateway:
> 
> spdadd LAN2PUB/32 LAN1PUB/32 ip4 -P in ipsec esp/transport//require;
> spdadd LAN1PUB/32 LAN2PUB/32 ip4 -P out ipsec esp/transport//require;
> 
> and of course the in/out bits reversed on the LAN2 gateway.  The 
> important bit is the ``ip4'' bit.  I don't expect connections to/from 
> the public IP numbers to be caught by the policy - and in fact run 
> NAT on both gateways.

I have this:

spdadd 10.0.2.0/26 10.0.2.128/28 any -P in ipsec 
esp/tunnel/209.167.75.124-209.167.75.123/require;
spdadd 10.0.2.128/28 10.0.2.0/26 any -P out ipsec
esp/tunnel/209.167.75.123-209.167.75.124/require;

Although now I'm slightly confused since I had switched from 'tunnel' to
'transport' after someone pointed out that since gif is a tunnel, I don't
have to rely on IPSec's 'tunnel' mode do do the encapsulation.

Am I getting bit by one-too-many layers of IPv4?

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Diagnostics question with PPPoE

[Matthew Emmerton]

Folks,

I'm supporting a retail store setup where stores connect to the head office
using IPSec over PPPoE links, handled by a FreeBSD 4.3 server.  Both IPSec
and PPPoE are working fine.  However, lately we've been having problems
where PPP will disconnect for some reason and reconnect.  Since I'm very
confident that FreeBSD's PPPoE  is rock solid, I'm trying to pin it down on
the ISP, which has a track record of making unannounced service outages.

Here's a log snippet of a typical disconnect:

Oct  2 13:03:43 belmont ppp[144]: tun0: Phase: deflink: open -> lcp
Oct  2 13:03:43 belmont ppp[144]: tun0: IPCP: deflink: LayerDown:
209.167.75.124
Oct  2 13:03:43 belmont ppp[144]: tun0: IPCP: deflink: State change
Opened --> Starting
Oct  2 13:03:43 belmont ppp[144]: tun0: IPCP: deflink: LayerFinish.
Oct  2 13:03:43 belmont ppp[144]: tun0: IPCP: Connect time: 15841 secs:
20512841 octets in, 3999315 octets out
Oct  2 13:03:43 belmont ppp[144]: tun0: IPCP: : 25041 packets in, 21506
packetsout
Oct  2 13:03:43 belmont ppp[144]: tun0: IPCP:  total 1547 bytes/sec, peak
71398 bytes/sec on Tue Oct  2 13:03:43 2001
Oct  2 13:03:43 belmont ppp[144]: tun0: IPCP: deflink: State change
Starting --> Initial
Oct  2 13:03:43 belmont ppp[144]: tun0: Phase: bundle: Terminate
Oct  2 13:03:46 belmont ppp[144]: tun0: Phase: deflink: Disconnected!
Oct  2 13:03:46 belmont ppp[144]: tun0: Phase: deflink: lcp -> logout
Oct  2 13:03:46 belmont ppp[144]: tun0: Phase: deflink: logout -> hangup
Oct  2 13:03:46 belmont ppp[144]: tun0: Phase: deflink: Disconnected!

How can I tell who is instigating the disconnect?

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: ppp(8) crashes 4.2-R when using netgraph(4) module

[Matthew Emmerton]

Dynamic loading of negraph modules is still broken, and probably won't be
fixed until 5.0 (at least that's what the comments on the zillion PRs
about this problem say.)

Add 'options NETGRAPH_ETHER' and 'options NEGRAPH_SOCKET' to your kernel
config file and rebuild your kernel.

-- 
Matthew Emmerton  || [EMAIL PROTECTED]
GSI Computer Services || http://www.gsicomp.on.ca

On Tue, 20 Nov 2001, Greg Black wrote:

> I rebuilt my 4.2-RELEASE kernel that has been in use for ages
> with the following extra lines in the config:
> 
> options   NETGRAPH#netgraph(4) system
> options   NETGRAPH_PPPOE
> 
> My earlier attempt to run ppp(8) on my new ADSL modem failed
> because netgraph was not in the kernel.
> 
> After building a clean new kernel and installing it with the new
> modules, I tried ppp again and got a panic after a few seconds.
> I've tried it about six times.  Most attempts got a panic (and I
> have typed up the console screen from one of them below), but
> some just skipped the panic and rebooted.
> 
> On some attempts, we got a little bit of logging from the ppp
> process.  Here's one such log:
> 
> 
> Nov 20 15:11:02 Using interface: tun0 
> Nov 20 15:11:02 deflink: Created in closed state 
> Nov 20 15:11:02 Command: default: set filter alive 0 deny icmp 
> Nov 20 15:11:02 Command: default: set filter alive 1 deny udp src eq 53 
> Nov 20 15:11:02 Command: default: set filter alive 2 deny udp dst eq 53 
> Nov 20 15:11:02 Command: default: set filter alive 3 permit 0 0 
> Nov 20 15:11:02 Command: bne-pi-adsl: set device PPPoE:xl0 
> Nov 20 15:11:02 Command: bne-pi-adsl: set authname  
> Nov 20 15:11:02 Command: bne-pi-adsl: set authkey  
> Nov 20 15:11:02 Command: bne-pi-adsl: set ifaddr 203.143.238.93 0.0.0.0/0 
> Nov 20 15:11:02 Command: bne-pi-adsl: add default HISADDR 
> Nov 20 15:11:02 Command: bne-pi-adsl: set timeout 0 
> Nov 20 15:11:02 Phase: PPP Started (foreground mode). 
> Nov 20 15:11:02 Phase: bundle: Establish 
> Nov 20 15:11:02 Phase: deflink: closed -> opening 
> 
> 
> Each line also had the following data after the date:
>  bambi ppp[95014]: tun0:
> 
> Here's the console screen on one panic:
> 
> 
> module_register: module netgraph already exists!
> linker_file_sysinit "netgraph.ko" failed to register! 17
> 
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x4
> fault code= supervisor write, page not present
> instruction pointer   = 0x8:0xc01c9e3f
> stack pointer = 0x10:0xd24c2c98
> frame pointer = 0x10:0xd24c2ca8
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, def32 1, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 77817 (ppp)
> interrupt mask= net
> trap number   = 12
> panic: page fault
> 
> syncing disks... 113 7 2
> done
> Uptime: 5m2s
> Automatic reboot in 15 seconds - press a key [rest elided]
> 
> 
> If anybody can point me in the right direction to solve this,
> I'll be very grateful.  My sole goal is to get ppp to talk to my
> ADSL modem, so if there's some other magic I should try, I'm
> happy to do that.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Strange problem with PPP/Netgraph (PPPoE)

[Matthew Emmerton]

I've got a bunch of FreeBSD 4.4 boxes doing PPPoE using netgraph and
PPP.  They've been doing this quite happily for a few months, but now one
of the boxes is sick.

[ Disclaimer:  I'm 150 miles away from the box, so I don't have exact log
messages.  What you see below is my simple paraphrasing. ]

What is happening is that when ppp starts on bootup (ppp -quiet -ddial
pppoe), the last entry is "dial -> carrier" and nothing else.  Normally we
get a "PPPOE hook suceeded (tun0)" message after that and it goes into the
LCP/IPCP phase.

I'd like to point the finger at the ISP (since they've had fun dropping
connections in the past and they swapped out the modem without telling us
-- long story, don't ask), but need to know how to interpret this message.  
Are we not getting any further because a) ppp can't talk to NETGRAPH, b)
NETGRAPH can't talk PPPoE to the DSL modem (bad NIC) or c) DSL modem isn't
passing along our data to the ISP (bad ISP.)

-- 
Matthew Emmerton  || [EMAIL PROTECTED]
GSI Computer Services || http://www.gsicomp.on.ca


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: ppp(8) crashes 4.2-R when using netgraph(4) module

[Matthew Emmerton]

> Greg Black wrote:
> Now, the final question:  I have to implement something similar
> on a 4.1-R system several thousand km away.  There's no question
> of upgrading it from 4.1 and I can't afford to have it panic.
> Is it reasonable to expect that PPPoE will work OK provided I
> add the netgraph stuff to the kernel and ensure the NIC is UP
> before running ppp?

Yes, that should look after all the gotchas.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Strange problem with PPP/Netgraph (PPPoE)

[Matthew Emmerton]

Thanks for all who replied to this thread, indicating that a bad cable was
likely the culprit.

In this case, changing the cable didn't help, but commenting out the
"ifconfig_rl0='up'" line in /etc/rc.conf fixed the problem.

Any ideas on why doing an 'ifconfig rl0 up' before starting PPP (using set
device PPPoE:rl0) would cause this problem?  (These machines are running
4.3-REL-p20)

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Very strange network behaviour - can anyone help me analyse tcpdump output?

[Matthew Emmerton]

Hi all,

In the continuing saga of IPSec over PPPoE for a retail POS environment that
I'm maintaing, the problems seem to become more complex as time goes on.

The network is quite simple:
[ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] - [
LAN #2 ]

Both LANs connect using PPPoE with the same ISP, and are one hop apart
(according to traceroute).

The problem is that a connection from the Internet (anywhere) to either of
the FreeBSD gateways will "hang".  Usually I can login but doing an 'ls -al'
will display a few lines of text and then nothing.  This happens using a
bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native, FreeBSD)
from various ISPs, as well as *between* the gateways, so the problem is most
definitely related to the ISP providing us service.  However, they seem to
think that it's our problem ("none of the customers that use Windows have
this problem -- must be that Unix thing that you're using").

I have an ethereal trace of a hanging telnet session from my desktop to one
of the gateway machines, and the corresponding tcpdump trace of the same
session on the gateway.  Since I'm not too familiar with TCP/IP at such a
low level, I was wondering if anyone would be willing to take a look at the
two dumps and see if there is anything strange going on.

Thanks,

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Very strange network behaviour - can anyone help me analyse tcpdump output?

[Matthew Emmerton]

> On Mon, 26 Nov 2001, Matthew Emmerton wrote:
>
> > Hi all,
> >
> > In the continuing saga of IPSec over PPPoE for a retail POS environment
that
> > I'm maintaing, the problems seem to become more complex as time goes on.
> >
> > The network is quite simple:
> > [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] -
[
> > LAN #2 ]
> >
> > Both LANs connect using PPPoE with the same ISP, and are one hop apart
> > (according to traceroute).
> >
> > The problem is that a connection from the Internet (anywhere) to either
of
> > the FreeBSD gateways will "hang".  Usually I can login but doing an
'ls -al'
> > will display a few lines of text and then nothing.  This happens using a
> > bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native,
FreeBSD)
> > from various ISPs, as well as *between* the gateways, so the problem is
most
> > definitely related to the ISP providing us service.  However, they seem
to
> > think that it's our problem ("none of the customers that use Windows
have
> > this problem -- must be that Unix thing that you're using").
>
> If you are using gif, make sure it has a small MTU (try 512 bytes)

belmont.heers.on.ca# ifconfig gif0
gif0: flags=8011 mtu 1280
inet 10.0.2.2 --> 10.0.2.130 netmask 0x
belmont.heers.on.ca# ifconfig gif0 mtu 512
ifconfig: ioctl (set mtu): Invalid argument
belmont.heers.on.ca# gifconfig gif0 mtu 512
gifconfig: mtu: bad value
belmont.heers.on.ca#

How am I supposed to change the MTU?
(These machines are running 4.3-RELEASE-p12)

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Very strange network behaviour - can anyone help me analysetcpdump output?

[Matthew Emmerton]

On Tue, 27 Nov 2001, Andre Oppermann wrote:

> Matthew Emmerton wrote:
> > 
> > Hi all,
> > 
> > In the continuing saga of IPSec over PPPoE for a retail POS environment that
> > I'm maintaing, the problems seem to become more complex as time goes on.
> > 
> > The network is quite simple:
> > [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] - [
> > LAN #2 ]
> > 
> > Both LANs connect using PPPoE with the same ISP, and are one hop apart
> > (according to traceroute).
> 
> This smells like MTU problems. Try to set the MTU on your physical LAN
> interfaces to something like 1480 or so any try again.

That's what I thought too.  I checked, and ppp is doing the TPC MSS
fixup.  Even after removing the gif/ipsec stuff that I was doing
(less overhead, and converting this installation into a plain
LAN-behind-NAT setup), the problem persists.

I tried dropping the MTU on my LAN interface to 1200 (from 1500), but that
didn't change anything.

If my ISP installed a bunch of really buggy hardware, would that explain
why this started happening recently without any changes on my side?

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: solved : ip change ? not according to tcpdump.

[Matthew Emmerton]

On Wed, 28 Nov 2001, Tariq Rashid wrote:

> 
>  apologies - natd was running on the interfaces which causes the effects.
> 
>  well - i didn't know that natd didn't respond to ip address changes...


It will, if you run it with the '-dynamic' flag.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Very strange network behaviour - can anyone help me analyse tcpdump output?

[Matthew Emmerton]

> > Matthew Emmerton wrote:
> > >
> > > Hi all,
> > >
> > > In the continuing saga of IPSec over PPPoE for a retail POS
environment that
> > > I'm maintaing, the problems seem to become more complex as time goes
on.
> > >
> > > The network is quite simple:
> > > [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway
#2 ] - [
> > > LAN #2 ]
> > >
> > > Both LANs connect using PPPoE with the same ISP, and are one hop apart
> > > (according to traceroute).
> >
> > This smells like MTU problems. Try to set the MTU on your physical LAN
> > interfaces to something like 1480 or so any try again.
>
> That's what I thought too.  I checked, and ppp is doing the TPC MSS
> fixup.  Even after removing the gif/ipsec stuff that I was doing
> (less overhead, and converting this installation into a plain
> LAN-behind-NAT setup), the problem persists.
>
> I tried dropping the MTU on my LAN interface to 1200 (from 1500), but that
> didn't change anything.
>
> If my ISP installed a bunch of really buggy hardware, would that explain
> why this started happening recently without any changes on my side?

The answer turned out to be quite obvious.  If I didn't make any changes on
the FreeBSD end, and the ISP didn't make any changes on their end, then it
must have been the telco (since these are DSL links.)

It turned out that the telco upgraded a bunch of line equipment recently
which didn't play nice with the DSL equipment that the ISP was using.  After
6 hours of testing the wiring between our DSL modem and various points all
the way back to the CO, the telco figured out the problem and the
strangeness that we saw has gone away.

Thanks for all the helpful hints and suggestions - it surely kept me from
going mad.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Strange situation with NAT and sendmail

[Matthew Emmerton]

I've got two networks -- A (10.0.0.0/24) and  B (192.168.0.0/24), both
behind NAT gateways.

The problem I'm having is that I cannot connect to the mail server on
network A (10.0.0.2) from any machine behind the NAT gateway on network B.
However, any system on network B can successfully ping the gateway of
Network A, as well as connect to the two HTTP servers running on the same
host as the mail server (10.0.0.2).  The mail server is running, since I can
connect to it from the NAT box on network A (via internal address) and via
public port-forwarded address from the NAT box on network B.

Why can't I connect to it from behind the network B's NAT gateway, when I
can connect fine to other services running on the same machine?

--
Matt Emmerton




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Strange situation with NAT and sendmail [ FIXED ]

[Matthew Emmerton]

> On Mon, Oct 15, 2001 at 07:28:49PM -0400, Matthew Emmerton wrote:
> > I've got two networks -- A (10.0.0.0/24) and  B (192.168.0.0/24), both
> > behind NAT gateways.
> >
> > The problem I'm having is that I cannot connect to the mail server on
> > network A (10.0.0.2) from any machine behind the NAT gateway on network
B.
> > However, any system on network B can successfully ping the gateway of
> > Network A, as well as connect to the two HTTP servers running on the
same
> > host as the mail server (10.0.0.2).  The mail server is running, since I
can
> > connect to it from the NAT box on network A (via internal address) and
via
> > public port-forwarded address from the NAT box on network B.
> >
> > Why can't I connect to it from behind the network B's NAT gateway, when
I
> > can connect fine to other services running on the same machine?
>
> My first guess would be to see if you're really "unable" to connect to
> sendmail. Check the configuration on sendmail to see if it's set up to
> do reverse lookups. It may be trying to resolve the IP you're connecting
> from. Try connecting and then let it sit until you see a time out (and
> running tcpdump on the box you're trying tp connect from will tell you
> if any packets are coming back).

I forgot to mention, the mail server on network A is running on *cough* NT
*cough*.  It is in the process of being replaced by a FreeBSD system with
sendmail, but not until the new year.

I did a tcpdump on the NAT box on network A - it never records any incoming
packets destined for port 25 whatsoever. However, it does record incoming
packets for port 81 (the administration web server for the mail server.)

Therein lies the answer.  It would appear that the ISP providing me
residential broadband has now started filtering outbound access to port 25 -
you can only send via their mail server.  This is why I can't connect to the
mail server on the remote network, but everything else works fine.

Sorry for the false alarm!

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: natd restart

[Matthew Emmerton]

> On Sat, 26 Jan 2002, Clemens Hermann wrote:
> 
> > Hi,
> > 
> > Is there a way to get natd to reload the config-file without
> > terminating?
> 
> There is a natd patch, running around here somewhere, that allows
> you to send a HUP signal to natd and have it reload the config.
> 
> You will have to search the mailling list archive to find out
> who/what/when/where/why etc.

Here's the patch that I wrote some time ago.  YMMV.

--
Matt Emmerton



natd.readcfg.patch
Description: Binary data

Re: natd restart

[Matthew Emmerton]

> Am 27.01.2002 um 02:11:30 schrieb Matthew Emmerton:
>
> Hi Matt,
>
> > Here's the patch that I wrote some time ago.
>
> thanks a lot!
> Did you send-pr the patch? It seems quite necessary to be added.

Not yet.  One of the things that I don't like about this patch is that old
rules still stay around (re-reading the configuration will only modify
existing rules and add new rules.)  I'm also taking a lot of flak on my side
of the fence since NAT runs as a userland process, so every packet gets
copied between the kernel and userland twice (once on the way in, once on
the way out.)  Apparently Linux doesn't do this.

I'm looking at making natd into a kernel option ("options IPNAT") and using
a combination of sysctls and a front-end program to manage how nat operates,
much like "options IPFIREWALL" and ipfw works today.

This (in my mind) should greatly enhance the throughput of FreeBSD's NAT and
keep those Linux people from bashing us (or me, at least.)

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: natd restart

[Matthew Emmerton]

> Am 27.01.2002 um 00:41:23 schrieb Rogier R. Mulhuijzen:
>
> Hi Roger,
>
> > What sort of changes are you talking about here? Maybe there's a
different
> > way of going about it.
>
> I want to move an existing network from 91.0.0.0/8 to 172.16.0.0/16.
> Furthermore name resolution changes from wins to dns and dhcp is no longer
> used.
> The whole story has to take place during normal operation and I can not
> enter a gateway on any machine.
> It will take ~2 weeks and there are ~100 computers.

Why not just add an IP alias for the "new" network on each machine?  Each
system will respond to packets directed to either network, but without the
complexity of a NAT box in the middle.  Once you've got everything switched,
then you can remove the original IP addresses.  I've used this method in the
past to transition LANs between IP ranges and it works absolutely fine.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: natd restart

[Matthew Emmerton]

> (order of quoted mail slightly altered)
>
> >I'm looking at making natd into a kernel option ("options IPNAT") and
using
> >a combination of sysctls and a front-end program to manage how nat
operates,
> >much like "options IPFIREWALL" and ipfw works today.

I've been told that 'options IPFILTER' with ipf(8) and ipnat(8) does NAT in
the kernel, whereas 'options IPDIVERT' and ipfw(8) and natd(8) is a userland
solution.

> I've been kicking around the idea of making it a netgraph node. And I know
> several other people have too.

This is probably the easiest starting point.

> libalias is very nice, natd to me has a hackey feeling to it. Try setting
> up a firewall that nats and uses dynamic rules I haven't been able to,
> have had to rely on natd to do my state checking, resulting in ipfw rule
> lists that are not easily read by the layman. So maybe that's another
> reason to re-evaluate our current NAT solution.

See the alternatives above.  Perhaps ipf might handle dynamic rules better?
( I don't know, since I've used ipfw since I started using FreeBSD.)

> Would it be hard to keep using libalias? I know we can't just link against
> userland libraries in kernel land, but would there be much difficulty in
> making use of the exact same code? Because the beauty of having libalias
is
> of course the -nat switch on ppp for instance

It would be nice to keep libalias functionality, since it is a very easy
interface to use.

> Does anything but ppp and natd use libalias?

A quick check of the sources says no.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: natd restart

[Matthew Emmerton]

> Am 27.01.2002 um 09:59:14 schrieb Matthew Emmerton:
>
> Hi Matthew,
>
> > Why not just add an IP alias for the "new" network on each machine?
Each
> > system will respond to packets directed to either network, but without
the
> > complexity of a NAT box in the middle.  Once you've got everything
switched,
> > then you can remove the original IP addresses.
>
> Sounds like a way better solution as the one I thought of.
> Thanks a lot for this hint!
>
> > I've used this method in the
> > past to transition LANs between IP ranges and it works absolutely fine.
>
> Did you use Windows machines in this setup?
> There are many NT4 Boxes, Win2k, some 98 and 95 computers here.

No, I used the alias trick on a bunch of UNIX and NT4 servers.  All of the
desktops on the LAN used DHCP so it was easy to change them.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: squeeze more performance out of natd?

[Matthew Emmerton]

>  i've spent a good number of hours RTFMs, trying to make the best of a bad
> situtaion: userland natd instead of kernel-space nat.

I've been told that if you use ipf and ipnat, then you get the benefit of
kernel-space NAT.  Have you investigated this to see how it compares to
natd/ipfw for your purposes?

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: ppp -nat fails with adsl, but ok with modem

[Matthew Emmerton]

What version of FreeBSD are you using?  The ppp included in early 4.x
distributions doesn't have the TCP MSS fixup code that is required to make
things work properly with a PPPoE connection, and cause the kinds of
symptoms that you describe.

Matt

- Original Message -
From: "Greg Black" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 22, 2002 10:39 PM
Subject: ppp -nat fails with adsl, but ok with modem


> I've had ppp -nat working just fine over a normal modem link,
> but it is not working at all well on my ADSL link to the same
> provider.
>
> To quantify "not working at all well", although I can ping and
> traceroute ok from the hosts on my LAN, HTTP and FTP traffic is
> so slow and bursty as to be useless.  Clicking on a link with
> Netscape will see short bursts of data with long periods (of a
> minute or more) where it says "stalled".
>
> Clicking on  from
> my gateway host gets the page in an eye-blink, but on the NAT
> hosts, it will take 40 seconds to load the top banner and the
> "FreeBSD GNOME News Flash" heading, then another delay of 40 or
> so seconds before the rest of the page will be displayed.  Even
> then, Netscape thinks it has stalled and keeps waiting for the
> last bit of data.
>
> With FTP, a small transfer (e.g., a directory listing of / on
> ftp.freebsd.org) will complete normally; but something slightly
> larger (e.g., a listing of /pub/FreeBSD on the same server),
> will produce:
>
> ftp> cd /pub/FreeBSD
> 250 CWD command successful.
> ftp> dir
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for '/bin/ls'.
> ftp: netin: Connection reset by peer
> 226 Transfer complete.
> ftp> quit
> 421 Timeout (60 seconds): closing control connection.
>
> If I do the same things from the host that is connected to the
> modem(s), everything works fine, for both types of connections.
>
> I'm finding this very frustrating, and I'm wondering if there's
> something weird about PPPoE with the ADSL link that needs some
> special magic in order for things to work properly.
>
> If anybody can point me at the truth, I'd be most grateful.
>
> Alternatively, if anybody can suggest steps I could take to
> identify the nature of the problem, that would also be most
> welcome.
>
> Greg Black
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: ppp -nat fails with adsl, but ok with modem

[Matthew Emmerton]

> "Matthew Emmerton" wrote:
>
> | From: "Greg Black" <[EMAIL PROTECTED]>
> | To: <[EMAIL PROTECTED]>
> | Sent: Friday, February 22, 2002 10:39 PM
> | Subject: ppp -nat fails with adsl, but ok with modem
> |
> | > I've had ppp -nat working just fine over a normal modem link,
> | > but it is not working at all well on my ADSL link to the same
> | > provider.
> | >
> | > To quantify "not working at all well", although I can ping and
> | > traceroute ok from the hosts on my LAN, HTTP and FTP traffic is
> | > so slow and bursty as to be useless.  Clicking on a link with
> | > Netscape will see short bursts of data with long periods (of a
> | > minute or more) where it says "stalled".
> | >
> | > Clicking on <http://www.freebsd.org/gnome/newsflash.html> from
> | > my gateway host gets the page in an eye-blink, but on the NAT
> | > hosts, it will take 40 seconds to load the top banner and the
> | > "FreeBSD GNOME News Flash" heading, then another delay of 40 or
> | > so seconds before the rest of the page will be displayed.  Even
> | > then, Netscape thinks it has stalled and keeps waiting for the
> | > last bit of data.
> | >
> | > With FTP, a small transfer (e.g., a directory listing of / on
> | > ftp.freebsd.org) will complete normally; but something slightly
> | > larger (e.g., a listing of /pub/FreeBSD on the same server),
> | > will produce:
> | >
> | > ftp> cd /pub/FreeBSD
> | > 250 CWD command successful.
> | > ftp> dir
> | > 200 PORT command successful.
> | > 150 Opening ASCII mode data connection for '/bin/ls'.
> | > ftp: netin: Connection reset by peer
> | > 226 Transfer complete.
> | > ftp> quit
> | > 421 Timeout (60 seconds): closing control connection.
> | >
> | > If I do the same things from the host that is connected to the
> | > modem(s), everything works fine, for both types of connections.
> | >
> | > I'm finding this very frustrating, and I'm wondering if there's
> | > something weird about PPPoE with the ADSL link that needs some
> | > special magic in order for things to work properly.
> | >
> | > If anybody can point me at the truth, I'd be most grateful.
> | >
> | > Alternatively, if anybody can suggest steps I could take to
> | > identify the nature of the problem, that would also be most
> | > welcome.
> | >
> | > Greg Black
> | >
> | > To Unsubscribe: send mail to [EMAIL PROTECTED]
> | > with "unsubscribe freebsd-net" in the body of the message
> |
> | What version of FreeBSD are you using?  The ppp included in early 4.x
> | distributions doesn't have the TCP MSS fixup code that is required to
make
> | things work properly with a PPPoE connection, and cause the kinds of
> | symptoms that you describe.
>
> The NAT box is running 4.2-RELEASE -- is that a problem?

Yes. This problem was first fixed in 4.2-STABLE.  There are two safe ways to
fix this:
- upgrade to a newer -RELEASE or -STABLE
- run the tcpmssd program (which is in the ports collection -
/usr/ports/net/tcpmssd)

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Hello from Mark Filipak

[Matthew Emmerton]

On Wed, 17 Apr 2002, Mark Filipak wrote:

> Hello All!
> 
> This is an introduction and a ping.
> 
> I live in Mansfield, Ohio, USA, and have some very specific problems and questions. 
>The first should probably be whether this is the right list for me so
> 
> I just installed GallantWEB. It is a pre-configured version of FreeBSD 3.3 that acts 
>as a gateway/firewall/server. It is up and running but doesn't recognize my D-Link 
>DFE-530TX+ ethernet cards.
> 
> What I have to work with
> 
> I have the full FreeBSD 3.3 distribution (6 discs) from Walnut Creek.
> 
> I have C source code and makefile for the D-Link DFE-530TX+ ethernet
> card. It was written for Linux. The name of the driver source code is
> Rtl8139.C.
> 
> I have Greg Lehey's book: "The Complete FreeBSD".
> 
> I also have the full FreeBSD 4.0 distribution (4 discs) from Walnut
> Creek, but I don't want to tackle that right now and would like to get
> 3.3 fully functional first.

The DFE-530TX+ driver was first supported in FreeBSD 4.4.

You'll inflict the least amount of pain if you just get a copy of
FreeBSD 4.4 or 4.5.

You might be able to backfit this driver to FreeBSD 4.0 -- I've
successfully done it for 4.2 and 4.3.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: SMC9432 not being recognized

[Matthew Emmerton]

> i was having problems with a SMC9432TX ethernet card.i
> already have a Realtek 1211TX configured on this
> machine.its just not recognizing this card.i am not
> getting a tx0 assigned.
> here's the dmesg below.hope somebody can give me
> useful pointer's.
> Thanks in advance,
> Vinod
>
> The Regents of the University of California. All
> rights reserved.
> FreeBSD 4.5-RELEASE #0: Mon Jan 28 14:31:56 GMT 2002
>
> [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC
> Timecounter "i8254"  frequency 1193182 Hz
> CPU: Pentium II/Pentium II Xeon/Celeron (333.27-MHz
> 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0x651  Stepping = 1
>
>
Features=0x183f9ff
> real memory  = 67108864 (65536K bytes)
> avail memory = 60649472 (59228K bytes)
> Preloaded elf kernel "kernel" at 0xc0496000.
> Pentium Pro MTRR support enabled
> md0: Malloc disk
> Using $PIR table, 7 entries at 0xc00fdf50
> npx0:  on motherboard
> npx0: INT 16 interface
> pcib0:  on
> motherboard
> pci0:  on pcib0
> pcib1: 
> at device 1.0 on
> pci0
> pci1:  on pcib1
> pci1:  at 0.0
> isab0:  at device 7.0
> on pci0
> isa0:  on isab0
> atapci0:  port
> 0xfc90-0xfc9f at device
> 7.1 on pci0
> ata0: at 0x1f0 irq 14 on atapci0
> ata1: at 0x170 irq 15 on atapci0
> uhci0:  port
> 0xfca0-0xfcbf irq
> 9 at device 7.2 on pci0
> usb0:  on
> uhci0
> usb0: USB revision 1.0
> uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00,
> addr 1
> uhub0: 2 ports with 2 removable, self powered
> chip1: 
> port 0x7000-0x700f
> at device 7.3 on pci0
> rl0:  port
> 0xf800-0xf8ff mem
> 0xfedffc00-0xfedffcff irq 11 at device 13.0 on pci0
> rl0: Ethernet address: 00:e0:29:32:36:7a
> miibus0:  on rl0
> rlphy0:  on miibus0
> rlphy0:  10baseT, 10baseT-FDX, 100baseTX,
> 100baseTX-FDX, auto
> pci0:  (vendor=0x1274, dev=0x1371) at
> 16.0 irq 9
> orm0:  at iomem
> 0xc-0xc7fff,0xe4000-0xe on isa0
> fdc0:  at port 0x3f0-0x3f5,0x3f7
> irq 6 drq 2 on
> isa0
> fdc0: FIFO enabled, 8 bytes threshold
> fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> atkbdc0:  at port
> 0x60,0x64 on isa0
> atkbd0:  flags 0x1 irq 1 on atkbdc0
> kbd0 at atkbd0
> psm0:  irq 12 on atkbdc0
> psm0: model IntelliMouse, device ID 3
> vga0:  at port 0x3c0-0x3df iomem
> 0xa-0xb on
> isa0
> sc0:  at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> sio0: type 16550A
> sio1: configured irq 3 not in bitmap of probed irqs 0
> ppc0:  at port 0x378-0x37f irq 7 on
> isa0
> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
> plip0:  on ppbus0
> lpt0:  on ppbus0
> lpt0: Interrupt-driven port
> ppi0:  on ppbus0
> ad0: 4110MB  [14848/9/63] at
> ata0-master
> UDMA33
> acd0: CDROM  at ata1-master
> using PIO4
> Mounting root from ufs:/dev/ad0s1a

There's not much to go on here.  The only "unknown device" is this:

> pci0:  (vendor=0x1274, dev=0x1371) at
> 16.0 irq 9

Which apparently is a Ensoniq AudioPCI device.

It appears that your system isn't even recognizing your SMC9432TX card.  I
have one of these cards, and I know FreeBSD will detect them.

Try yanking your RealTek card and seeing if the tx0 magically appears.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Problems with PPP and one annoying ISP

[Matthew Emmerton]

I've got this ISP who won't provide support for UNIX that I have to get
working on UNIX.

I can dial up to the ISP perfectly fine using Windows 95, but whenever I try
and configure my FreeBSD machine to dial up, ppp never works right.

Here's the chunk of my ppp.conf:

[dumbisp]
 set authname 
 set authkey 
 set phone 17603320155
 add default HISADDR

As you can see, pretty plain-vanilla.

When I dial interactively, I see "PPp>" and then the modem hangs up.  I'm
not sure why, but it just is.  I'm passing the PAP authentication phase, so
I know I haven't typed in my password incorrectly.

Attached is the output in /var/log/ppp.log (gzipped, since hub refused my
message the first time around.).  If there are any PPP wizards
out there who can help me through this, it would be greatly appreciated.

--
Matt Emmerton




ppp.log.gz
Description: GNU Zip compressed data

Re: Problems with PPP and one annoying ISP

[Matthew Emmerton]

Sadly, no.  The connection comes down even if I specify the static IP (with
or without the netmask) that we're supposed to get.  I left it out because
on Win95 I say "obtain IP address automatically" which DTRT.

Matt

- Original Message -
From: "Brian Somers" <[EMAIL PROTECTED]>
To: "Matthew Emmerton" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, June 11, 2002 10:11 PM
Subject: Re: Problems with PPP and one annoying ISP


> Hi,
>
> Does it make a difference if you
>
>   set ifaddr x.x.x.x y.y.y.y
>
> in your config ?  Perhaps your ISP is expecting you to specify an IP
> number  I'm guessing this because the peer is bringing things down
> as soon as you send an IPCP request for 0.0.0.0.
>
> On Tue, 11 Jun 2002 21:27:48 -0400, "Matthew Emmerton"
<[EMAIL PROTECTED]> wrote:
> > I've got this ISP who won't provide support for UNIX that I have to get
> > working on UNIX.
> >
> > I can dial up to the ISP perfectly fine using Windows 95, but whenever I
try
> > and configure my FreeBSD machine to dial up, ppp never works right.
> >
> > Here's the chunk of my ppp.conf:
> >
> > [dumbisp]
> >  set authname 
> >  set authkey 
> >  set phone 17603320155
> >  add default HISADDR
> >
> > As you can see, pretty plain-vanilla.
> >
> > When I dial interactively, I see "PPp>" and then the modem hangs up.
I'm
> > not sure why, but it just is.  I'm passing the PAP authentication phase,
so
> > I know I haven't typed in my password incorrectly.
> >
> > Attached is the output in /var/log/ppp.log (gzipped, since hub refused
my
> > message the first time around.).  If there are any PPP wizards
> > out there who can help me through this, it would be greatly appreciated.
> >
> > --
> > Matt Emmerton
>
> --
> Brian <[EMAIL PROTECTED]>   <[EMAIL PROTECTED]>
>   <http://www.Awfulhak.org>
> Don't _EVER_ lose your sense of humour !   
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Sympatico ADSL connection through a hub

[Matthew Emmerton]

In your /etc/rc.conf, are you setting an IP address for the dc0 interface?
If you are, then PPPoE won't work properly since the interface is already up
and running.

Check for a line that looks like this:

ifconfig_dc0="inet 10.0.0.1 netmask 0xfffc"

If a line like this exists, comment it out (put a # sign in front of it) and
then reboot.

--
Matt

- Original Message -
From: "Alexis Georges" <[EMAIL PROTECTED]>
To: "Damian Gerow" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, October 08, 2002 10:53 AM
Subject: Re: Sympatico ADSL connection through a hub


> thanks for helping damian..i did everything you gave me but it still
doesn't
> seem to work..
> here is what i have after doing everything, and typing ifconfig
>
> dc0: flags:88c3  mtu
1500
> inet6 fe80::2a0:ccff::fee1: 8be5%dc0 prefixlen 64 scopeid 0x1
> inet 10.0.1 netmask 0xfffc broadcast 10.0.0.3
> ether 00:a0:cc:e1:8be5
> media: Ethernet 10baseT/UTP
> status: active
> tun0: flags=8051  mtu 1500
> inet6 fe80:2a0:ccff:fee1: 8be5%tun0 prefixlen 64 scopeid 0x7
> opened by PID 54
>
> thats all i get..shouldn't i have an IP address somewhere other than the
> 10.0.0.1..on windows i used to have 192.168.0.110(it will change since its
> dynamic) , but it only shows the 10.0.0.1 one..on another computer in the
> same home network, i got this info:
>
> netmask = 255.255.255.0
> default gateway = 192.168.0.1
> DNS server = 198.235.216.114 and 207.236.176.12
>
> to see if it had worked i tried pinging an address of another computer on
> the network and it just froze at the first "ping  blahblah 56"
> (something like taht)..
> what wrong?
> thanks again
>
> alexis
> - Original Message -
> From: "Damian Gerow" <[EMAIL PROTECTED]>
> To: "alexis georges" <[EMAIL PROTECTED]>
> Sent: Tuesday, October 08, 2002 5:30 AM
> Subject: Re: Sympatico ADSL connection through a hub
>
>
> > Spake alexis georges on 07/10/2002, 16:55:16 +:
> > > This is my first message posted to the list..hehehe
> > > anyways, i used to have a simple cable connection, which would be
> > > automatically comfigured by FreeBSD upon installation..I just moved
and
> now
> > > we have an ADSL connection (from Sympatico).. The connection is not
> > > configured automatically..so i looked on the web for a solution. I
found
> a
> > > few pages explaining that i had to recompile my kernel with a few
lines
> such
> > > as 'options NETGRAPH'..and that i had to write some info into the
> ppp.conf
> > > file..i did those things but apparently it doesn't work..I am not sure
> how
> > > to work this out..cuz all the solutions i found were the same..
> > > So i will explain exactly how i am connected to the internet..
> >
> > > 1. I have an ethernet card connected to a hub.
> > > 2. This hub is itself connected to the actual modem that we received
> from
> > > Sympatico.
> >
> > > On Windowsl, the conection wont work unless the connection type is set
> to
> > > 10Mb Half-Duplex..so i am guessing it should be the same on FreeBSD..
> > > also, the address is supposed to be obtained dynamically..(on windows
it
> > > says the address has been obtrained by DHCP, however, during FreeBSD
> > > installation, it fails to find the parameter for the connection)does
> that
> > > mean that instead of the 10.0.0.1 address teh solution form the web
gave
> me,
> > > i should put the address that i am using on windows (even though it
> shouild
> > > be a dynamic address?)
> > > Anyways, i would really like to be able to fix this..if anyone could
> help,
> > > that would be great..i wanna get rid of windows
> >
> > I work for a small ISP in Ontario, and while we don't offer service in
> > Quebec, and are in competition with Sympatico , here's what I've
> > done to get my machine up and running on an ADSL link:
> >
> > 1) Make sure these are in the kernel:
> >
> > pseudo-device   tun
> > options NETGRAPH
> > options NETGRAPH_ASYNC
> > options NETGRAPH_ETHER
> > options NETGRAPH_IFACE
> > options NETGRAPH_KSOCKET
> > options NETGRAPH_PPPOE
> > options NETGRAPH_SOCKET
> > pseudo-device   bpf# (I'm not sure this is needed, but
> ># it's nice to have.)
> >
> > As well as your normal networking code -- LIBMCHAIN if you want it,
> > RANDOM_IP_ID (really good idea to put in), and your devices.
> >
> > 2) Update your sources, build a new world and kernel.  Install,
> >reboot.
> > 3) In /etc/ppp/ppp.conf, add a new section called 'pppoe' or 'adsl':
> >
> > pppoe:
> >  set device PPPoE:rl0:
> >  set speed sync
> >  enable lqr
> >  set lqrperiod 3
> >  set cd 5
> >  set dial
> >  set login
> >  set timeout 0
> >  set authname @sympatico.ca
> >  set authkey 
> >  set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
> >  add default HISADDR
> >  disable dns
> >  disable vjcomp
> >  disable ipv6cp
> >
> > Note that with Sympatico, you *must* have 'disable vjcomp' in there.
> >

Re: SAPDB port for FreeBSD

[Matthew Emmerton]

> Hello FreeBSD gurus,
>
> I was surprised; there are no SAPDB (www.sapdb.org) in
> http://www.freebsd.org/ports/databases.html list!
> Has someone tried to install SAPDB on FreeBSD? Is it possible to create
new
> port?

I tried about a year or so ago, but gave up.  The SAPDB "build tools" are
extremely Linux-centric (they expect a LSB-compliant filesystem layout, and
it's next to impossible to trick it, as paths are hardcoded everywhere).
Furthermore, the actual SAPDB product is again, Linux-centric and has all
the warts that one would expect.

I eventually gave up and just ran it in Linux emulation -- much less effort
than making a FreeBSD port.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: How do I specify a unit for ppp?

[Matthew Emmerton]

- Original Message -
From: "Dan Langille" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 02, 2003 8:12 AM
Subject: How do I specify a unit for ppp?


> >From man ppp I see this:
>
>   The -unit flag tells ppp to only attempt to open /dev/tunN.
>
> I want it to use tun0.  I can't see a way to specify a unit in
> /etc/rc.conf.
>
> Clues?
> --
> Dan Langille : http://www.langille.org/

We really need a ppp_flags variable in /etc/rc.conf which is recognized by
/etc/rc.network for this kind of thing.
Then you could specificy ppp_flags="-unit 0" in /etc/rc.conf and be on your
way.

Patches against 4.7-REL (sorry, I don't have an up-to-date -stable box).
Comments requested; I will submit a PR with patches against -stable later
today.

--- rc.network.orig Wed Apr  2 08:23:43 2003
+++ rc.network  Wed Apr  2 08:24:07 2003
@@ -284,7 +284,7 @@
;;
esac

-   ppp_command="${ppp_command} ${ppp_profile}"
+   ppp_command="${ppp_command} ${ppp_flags} ${ppp_profile}"

echo "Starting ppp as \"${ppp_user}\""
su -m ${ppp_user} -c "exec ${ppp_command}"

--- defaults/rc.conf.orig   Wed Apr  2 08:23:12 2003
+++ defaults/rc.confWed Apr  2 08:23:36 2003
@@ -108,6 +108,7 @@
 ppp_nat="YES"  # Use PPP's internal network address translation or
NO.
 ppp_profile="papchap"  # Which profile to use from /etc/ppp/ppp.conf.
 ppp_user="root"# Which user to run ppp as
+ppp_flags=""   # Additional flags to pass to ppp(8).

 ### Network daemon (miscellaneous) ###
 syslogd_enable="YES"   # Run syslog daemon (or NO).

--
Matt Emmerton

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: help needed regarding named please

[Matthew Emmerton]

> I got an error while adding a zone in my named configuration, the zone is
properly setted and added in named.conf. Here is the error I got in
/var/log/message:
>
> Jun  4 05:49:36 webhosting named[37915]: master zone "lamedomain.com" (IN)
rejected due to errors (serial 2003040614)
> Jun  4 05:49:36 webhosting named[37915]: zones/lamedomain.com:12: Database
error near (ns3.isp.com.)
> Jun  4 05:49:36 webhosting named[37915]: zones/lamedomain.com:13: Database
error near (ns3.isp.com.)
> Jun  4 05:49:36 webhosting named[37915]: zones/lamedomain.com:15: Database
error near (ns3.isp.com.)
>
> Can someone help me resolving this please ? Or is there a way that named
don't care about that serial and take new zones in charge even if this
serial is "not good" ?
>
> Thanks in advance for the answer!

The serial is not the problem (it's just telling you that so you know which
version of the zone is causing problems) . The real problems are on line 12,
13 and 15 of your config file.

--
Matt Emmerton

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PLEASE HEEEEEELLLLPPPP ME...

[Matthew Emmerton]

Or, switch to using IPFILTER/IPNAT which has special features to handle the
case of FTP.

MAtt

> Your problem is that the ports you have allowed are not the only ports FTP
> uses.  FTP makes use of two separate TCP connections.
>
> The first is the command connection ( 21/tcp) which is the connection used
> for logging in , and issuing commands.  However when you make a data
> connection ( retrieving a file, listing a directory) a data connection is
> opened up.   Traditionally , port 20/tcp ( ftp-data) was used.   The
process
> being that the server opened a connection to your client machine from port
> 20.
>
> This clearly has issues when combined with firewalls and NAT.
>
> The other FTP transfer mode is Passive mode.  Here, a data request is
made,
> and the server provides details of what port the client should connect to.
>
> The problem you are seeing is because you are not natting all the possible
> ports through.  The best suggestion I have is to install something like
> jftpgw which will run on your firewall/gateway and act as a FTP proxy back
> to the FTP server.
>
>
> Regards,
>
> Barry
>
> - Original Message - 
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, July 23, 2003 1:51 PM
> Subject: PLEASE HEE ME...
>
>
> > please HELP !!!
> >
> >
> > Ok... here is my problem that I tried to explain completly !
> >
> > The situation is the one below:
> >
> > =
> > |SpeedToucheHome Ethernet ADSL Modem|
> > |10.0.0.138/24  |
> > =
> > |
> >10.0.0.0/24
> > |
> > ==
> > |   10.0.0.1/24   |
> > |  (A)  10.1.0.254/24 |- 10.1.0.0/24 -  (... DMZ ...)
> > | 192.168.1.254/24|
> > ==
> >|
> >   192.168.1.0/24
> >|
> >   ...
> >  clients workstations
> >
> >
> > My problem is about the computer A which does not what I would like It
> does.
> >
> > Currently, this computer has a customized kernel with thoses options:
> > IPFIREWALL
> > IPDIVERT
> >
> > but not IPFILTER !!! maybe it is the problem, I don't know !
> >
> > in the rc.conf, I made the following configuration
> > firewall_enabled="YES"
> > firewall_type="SIMPLE"  (but I tried too with OPEN")
> >
> > natd_enable="YES"
> > natd_interface="tun0"   (this is the interface for PPPoE, I think)
> > natd_flags="-f /etc/natd.conf"
> >
> > ...
> >
> >
> > and in natd.conf:
> > dynamic
> > interface tun0
> > redirect_port tcp 10.1.0.1:20-21 20-21
> >
> >
> > 10.1.0.1 is the IP address from my FTP server which is a computer placed
> in the
> > DMZ.
> >
> > My problem is: "from outside, I cannot access to the FTP server..."
> >
> > What I can say is:
> > First: My FTP server is OK because from inside, I can access to it from
> any
> > computer in DMZ or from clients workstations.
> > Secund: The answer to an outside request is "connection closed by host".
> > Third: Interface tun0 (the virtual interface for PPPoE) receives the ftp
> > request but does not forward them to ed1 (the outside netcard from A and
> > configured with 10.0.0.1). (I discoverd that with tcpdump).
> >   (the others interfaces get no more ftp packets from tun0)...
> >
> > So, what can I do to solve this problem...
> >
> > Thank you
> >
> > Sylvain.
> > ___
> > [EMAIL PROTECTED] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PnP VendorID list

[Matthew Emmerton]

> Where can I get list of officially assigned PnP Vendor IDs?
> I have a noname PnP ISA NIC that does not work.

There is no "official" list (at least for free access), but the "unofficial"
list is here: http://www.yourvote.com/pci/

--
Matt Emmerton

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PnP VendorID list

[Matthew Emmerton]

> Matthew Emmerton wrote:
> >
> > > Where can I get list of officially assigned PnP Vendor IDs?
> > > I have a noname PnP ISA NIC that does not work.
> >
> > There is no "official" list (at least for free access), but the
"unofficial"
> > list is here: http://www.yourvote.com/pci/
>
> Hmm, I have not PCI, I have ISA PnP device.

My apologies for reading your message too quickly.

> Are PCI and PnP vendor IDs related?

I don't know.  There's a remote possibility that they might be, but that
would be "too easy".

--
Matt Emmerton

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"