Just to point something out...

-----
# route show
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu  Interface
default            0.0.0.1            UGS         0     3757      -   pppoe0
0.0.0.1            default            UH          0        0      -   pppoe
# ping -c 2 google.com
PING google.com (216.239.37.99): 56 data bytes
64 bytes from 216.239.37.99: icmp_seq=0 ttl=245 time=98.521 ms
64 bytes from 216.239.37.99: icmp_seq=1 ttl=245 time=99.414 ms
--- google.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 98.521/98.967/99.414/0.546 ms
-----

Seems normal the routing output

Might sound a stupid question, but are your nameservers ok? (Ok, you
proboably thought of that and are pinging an ip...)

On 23/05/05, Chris Zakelj <[EMAIL PROTECTED]> wrote:
> Ok, this probably isn't too big a surprise to frequent readers, but I'm
> having trouble with the new kernelized pppoe.  From the console messages
> below, it looks like it's "dialing" (for lack of a better term) and
> logging in successfully:
> 
> May 23 00:42:47 bbhhs96 /bsd: pppoe0: phase establish
> May 23 00:42:47 bbhhs96 /bsd: pppoe0: phase authenticate
> May 23 00:42:49 bbhhs96 /bsd: pppoe0: phase network
> 
> ifconfig seems to support this:
> 
> newtest# ifconfig
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
>         inet 127.0.0.1 netmask 0xff000000
>         inet6 ::1 prefixlen 128
>         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         address: 00:d0:b7:a0:dd:3f
>         media: Ethernet autoselect (10baseT)
>         status: active
>         inet6 fe80::2d0:b7ff:fea0:dd3f%fxp0 prefixlen 64 scopeid 0x1
> fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         address: 00:a0:c9:77:80:0d
>         media: Ethernet autoselect (100baseTX full-duplex)
>         status: active
>         inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255
>         inet6 fe80::2a0:c9ff:fe77:800d%fxp1 prefixlen 64 scopeid 0x2
> ral0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
>         address: 00:11:50:14:f6:a0
>         ieee80211: nwid "" 100dBm
>         media: IEEE802.11 autoselect
>         status: no network
> pflog0: flags=0<> mtu 33224
> pfsync0: flags=0<> mtu 2020
> enc0: flags=0<> mtu 1536
> pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
>         dev: fxp0 state: session
>         sid: 0x50f4 PADI retries: 3 PADR retries: 0 time: 0:1:2
>         inet 68.77.176.95 --> 0.0.0.1 netmask 0xffffffff
>         inet6 fe80::2d0:b7ff:fea0:dd3f%pppoe0 ->  prefixlen 64 scopeid 0x8
> 
> The IP address looks valid, and it's in the same the netblocks I was
> being assigned previously, but the gateway isn't being updated.  100%
> packet loss when pinging a remote host confirms this.  I have not
> activated PF yet, since knowing the connection itself is working is
> rather important before I throw filtering into the mix.  My
> /etc/hostname.pppoe0 is taken nearly verbatim from the pppoe(8) man page:
> 
> newtest# cat /etc/hostname.pppoe0
> pppoedev fxp0
> !/sbin/ifconfig fxp0 up
> !/usr/sbin/spppcontrol \$if myauthproto=pap [EMAIL PROTECTED]
> myauthkey=imnottellin
> !/sbin/ifconfig \$if inet 0.0.0.0 0.0.0.1 netmask 0xffffffff
> !/sbin/route add default 0.0.0.1
> up
> 
> According to the manpage, 0.0.0.1 is considered a remote-assigned
> wildcard, but it doesn't seem to actually be working that way (I also
> tried 0.0.0.0 just in case).  I removed the /etc/mygate file that was
> created during the install process, so that's not getting in the way,
> either.  The IPv4 routing table after roughly 5 minutes:
> 
> newtest# route show
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags    Refs      Use    Mtu
> Interface
> default            0.0.0.1            UGS         0        3      -   pppoe0
> 0.0.0.1            default            UH          0        0      -   pppoe0
> loopback           localhost          UGRS        0        0  33224   lo0
> localhost          localhost          UH          0        0  33224   lo0
> 192.168.0/24       link#2             UC          0        0      -   fxp1
> BASE-ADDRESS.MCAST localhost          URS         0        0  33224   lo0
> 
> I'm guessing I'm missing something that's probably obvious, but being
> obvious, it's eluding me.  Someone have a cluestick handy?  Oh, dmesg...
> 
> newtest# cat /var/run/dmesg.boot
> OpenBSD 3.7 (GENERIC) #50: Sun Mar 20 00:01:57 MST 2005
>     [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 171 MHz
> cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
> cpu0: F00F bug workaround installed
> real mem  = 100245504 (97896K)
> avail mem = 84451328 (82472K)
> using 1249 buffers containing 5115904 bytes (4996K) of memory
> mainbus0 (root)
> bios0 at mainbus0: AT/286+(c8) BIOS, date 02/26/97, BIOS32 rev. 0 @ 0xfb340
> apm0 at bios0: Power Management spec V1.2
> apm0: APM engage (device 1): power management disabled (1)
> apm0: AC on, battery charge unknown
> pcibios0 at bios0: rev 2.1 @ 0xf0000/0xb804
> pcibios0: PCI BIOS has 6 Interrupt Routing table entries
> pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371SB ISA" rev 0x00)
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc0000/0x8000 0xc8000/0x1000
> cpu0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82437VX" rev 0x02
> pcib0 at pci0 dev 7 function 0 "Intel 82371SB ISA" rev 0x01
> pciide0 at pci0 dev 7 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibili
> ty
> wd0 at pciide0 channel 0 drive 0: <QUANTUM FIREBALL EX13.6A>
> wd0: 16-sector PIO, LBA, 12970MB, 26563824 sectors
> wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
> wd1 at pciide0 channel 1 drive 0: <Maxtor 91024U2>
> wd1: 16-sector PIO, LBA, 9770MB, 20010816 sectors
> wd1(pciide0:1:0): using PIO mode 4, DMA mode 2
> fxp0 at pci0 dev 8 function 0 "Intel 82557" rev 0x08, i82559: irq 11,
> address 00:d0:b7:a0:dd:3f
> inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
> fxp1 at pci0 dev 9 function 0 "Intel 82557" rev 0x02: irq 10, address
> 00:a0:c9:77:80:0d
> inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 0
> vga1 at pci0 dev 10 function 0 "S3 ViRGE DX/GX" rev 0x01
> wsdisplay0 at vga1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> ral0 at pci0 dev 11 function 0 "Ralink RT2560" rev 0x01: irq 12, address
> 00:11:50:14:f6:a0
> ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525
> isa0 at pcib0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0 (mux 1 ignored for console): console keyboard, using
> wsdisplay0
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0: <PC speaker>
> sysbeep0 at pcppi0
> lpt0 at isa0 port 0x378/4 irq 7
> npx0 at isa0 port 0xf0/16: using exception 16
> pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> pccom0: console
> fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
> fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
> biomask e36d netmask ff6d ttymask ffef
> pctr: 586-class performance counters and user-level cycle counter enabled
> dkcsum: wd0 matched BIOS disk 80
> dkcsum: wd1 matched BIOS disk 81
> root on wd0a
> rootdev=0x0 rrootdev=0x300 rawdev=0x302
> 
> 


-- 
Random number generation is far too important to be left to chance!

Reply via email to