Network setup questions
Well, I've asked 3 or 4 times now in the last 3 weeks, and haven't received any answers. Posted to comp.unix.bsd.freebsd.misc and to both questions- and [EMAIL PROTECTED] That leads me to conclude that either I'm: asking the wrong question(s), asking in an improper manner or asking the wrong people/wrong group. I *have* searched Deja, I *have* read the docs and attempted to get this to work - I really don't know where else I could be looking or asking for more information. If my question was worded poorly or inappropiate, I would appreciate a pointer as to where/how/who I might contact in order to get my system up and configured properly. Again, I'm trying to log into an ISP via PPTP for internet access, using mpd-netgraph but also trying out pptpclient. I have a small home LAN that I want to NAT/IPFW such that all machines can share the internet connection. I'm running FreeBSD 4.4-Stable. Regards, Thor _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Network setup questions
Thor Legvold wrote: > > Well, I've asked 3 or 4 times now in the last 3 weeks, and haven't received > any answers. Posted to comp.unix.bsd.freebsd.misc and to both questions- and > [EMAIL PROTECTED] > > That leads me to conclude that either I'm: asking the wrong question(s), > asking in an improper manner or asking the wrong people/wrong group. I just subscribed yesterday so i don't know 'bout that. :) > I *have* searched Deja, I *have* read the docs and attempted to get this to > work - I really don't know where else I could be looking or asking for more > information. If my question was worded poorly or inappropiate, I would > appreciate a pointer as to where/how/who I might contact in order to get my > system up and configured properly. > > Again, I'm trying to log into an ISP via PPTP for internet access, using > mpd-netgraph but also trying out pptpclient. I have a small home LAN that I > want to NAT/IPFW such that all machines can share the internet connection. > I'm running FreeBSD 4.4-Stable. Well.. hmm eh.. what's your question ? > Regards, > Thor > Regards, Joao To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Network setup questions
"Thor Legvold" wrote: | Well, I've asked 3 or 4 times now in the last 3 weeks, and haven't received | any answers. Posted to comp.unix.bsd.freebsd.misc and to both questions- and | [EMAIL PROTECTED] | | That leads me to conclude that either I'm: asking the wrong question(s), | asking in an improper manner or asking the wrong people/wrong group. | | I *have* searched Deja, I *have* read the docs and attempted to get this to | work - I really don't know where else I could be looking or asking for more | information. If my question was worded poorly or inappropiate, I would | appreciate a pointer as to where/how/who I might contact in order to get my | system up and configured properly. | | Again, I'm trying to log into an ISP via PPTP for internet access, using | mpd-netgraph but also trying out pptpclient. I have a small home LAN that I | want to NAT/IPFW such that all machines can share the internet connection. | I'm running FreeBSD 4.4-Stable. First, don't cross-post; stick to freebsd-questions for now. Second, what is your question? 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
Julian Elischer wrote: | > I took the easy way out here and just ran | > | > ifconfig xl0 inet 10.0.0.1 | | Why put an IP address on it? | | ifconfig xl0 up I left out a detail. The modem has its own 10.x.x.x address and I was killing two birds with one stone -- this makes it easy to talk to the modem as well as bringing it up. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Network setup questions
Hi Joao, >Well.. hmm eh.. what's your question ? > I just posted it a few minutes ago to freebsd-questions (again). Else a quick search in the archives will show it (search word VPN PPTP mpd). I was asked not to cross post, but I can also send a copy to you privately if you would like. >Regards, >Joao Regards, Thor _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
kernel backtrace for kern/28844
Title: kernel backtrace for kern/28844
We had to wait 10 days for the next kernel crash to happily collect our crash dump (people who were using the system at that moment to route their remote maintance job were not so happy...).
It appears that the argument m to m_freem() is corrupt, but the value of m in the context of the caller is 0. This could mean we have corrupted stack, or maybe I simply don't understand gdb (I never used it before). As the contents of sc show, the code was handling interface de1 at the moment of the crash.
If you need more information, please let me know.
Greetings,
Rudi Mathijssen
# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) symbol kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec /var/crash/kernel.2
(kgdb) core /var/crash/vmcore.2
IdlePTD 2965504
initial pcb at 263de0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x79c02812
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0164da8
stack pointer = 0x10:0xc020
frame pointer = 0x10:0xc02c
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 = Idle
interrupt mask = net
trap number = 12
panic: page fault
syncing disks...
done
Uptime: 10d10h58m20s
dumping to dev #da/0x20001, offset 1737856
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:469
469 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc014ab7f in boot (howto%6) at ../../kern/kern_shutdown.c:309
#2 0xc014aefc in poweroff_wait (junk=0xc023c0cf, howto=0)
at ../../kern/kern_shutdown.c:556
#3 0xc02060e5 in trap_fatal (frame=0xc0244400, eva 42636306)
at ../../i386/i386/trap.c:951
#4 0xc0205dbd in trap_pfault (frame=0xc0244400, usermode=0, eva 42636306)
at ../../i386/i386/trap.c:844
#5 0xc02059a3 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = -2147483632,
tf_edi = 6717472, tf_esi = -1064284928, tf_ebp = -1071365044,
tf_isp = -1071365076, tf_ebx = 2042636288, tf_edx = 0,
tf_ecx = -1066018816, tf_eax = -6717473, tf_trapno = 12, tf_err = 0,
tf_eip = -1072280152, tf_cs = 8, tf_eflags = 66054,
tf_esp = -1053560832, tf_ss = 2147430528}) at ../../i386/i386/trap.c:443
#6 0xc0164da8 in m_freem (m=0xc0904d00) at ../../kern/uipc_mbuf.c:525
#7 0xc01a54b5 in tulip_tx_intr (sc=0xc133f000) at ../../pci/if_de.c:3715
#8 0xc01a5cf1 in tulip_txput (sc=0xc133f000, m=0xc08d2100)
at ../../pci/if_de.c:4299
#9 0xc01a6421 in tulip_ifstart_one (ifp=0xc133f018) at ../../pci/if_de.c:4740
#10 0xc018bc1c in ether_output_frame (ifp=0xc133f018, m=0xc08d2100)
at ../../net/if_ethersubr.c:401
#11 0xc018bb8a in ether_output (ifp=0xc133f018, m=0xc08d2100, dst=0xc02650d4,
rt0=0xc142b000) at ../../net/if_ethersubr.c:354
#12 0xc019856f in ip_output (m0=0xc0765400, opt=0x0, ro=0xc02650d0, flags=1,
imo=0x0) at ../../netinet/ip_output.c:787
#13 0xc0197d04 in ip_forward (m=0xc0765400, srcrt=0)
at ../../netinet/ip_input.c:1552
#14 0xc0196f0e in ip_input (m=0xc0765400) at ../../netinet/ip_input.c:563
#15 0xc019713f in ipintr () at ../../netinet/ip_input.c:759
#16 0xc01fc675 in swi_net_next ()
(kgdb) up 6
#6 0xc0164da8 in m_freem (m=0xc0904d00) at ../../kern/uipc_mbuf.c:525
525 if (m == NULL)
(kgdb) print m
$1 = (struct mbuf *) 0x668020
(kgdb) print *m
cannot read proc at 0
(kgdb) up 1
#7 0xc01a54b5 in tulip_tx_intr (sc=0xc133f000) at ../../pci/if_de.c:3715
3715 m_freem(m);
(kgdb) print m
$2 = (struct mbuf *) 0x0
(kgdb) echo print sc
$4 = (tulip_softc_t *) 0xc133f000
(kgdb) print *sc
$5 = {tulip_ifmedia = {ifm_mask = 0, ifm_media = 0, ifm_cur = 0xc071c600,
ifm_list = {lh_first = 0xc071c600},
ifm_change = 0xc01a46f4 ,
ifm_status = 0xc01a4774 }, tulip_ac = {ac_if = {
if_softc = 0xc133f000, if_name = 0xc022a53d "de", if_link = {
tqe_next = 0xc1340018, tqe_prev = 0xc071b020}, if_addrhead = {
tqh_first = 0xc132c700, tqh_last = 0xc1423f10}, if_pcount = 0,
if_bpf = 0x0, if_index = 2, if_unit = 1, if_timer = 1,
if_flags = -3
Re: Garbage tacked onto end of packet
In article [EMAIL PROTECTED]> you write: >[Bcc to Przemyslaw Frasunek who submitted the example in case >he can tell what hardware was involved] > >On Wed, Nov 21, 2001 at 02:36:56PM +0100, Dag-Erling Smorgrav wrote: >> http://lcamtuf.coredump.cx/mobp/ >> >> See Exhibit 5. Is this a known bug? > >Looks more like one or more bugs in a specific device driver, tcpdump or bpf. > >Here we have a short IP packet (44 bytes) which is later shown as having >46 and then 64 bytes. > >On the wire, ethernet frames are supposed to have at least 64 bytes (including >CRC ?) which is exactly 14+46+4 -- so the second example makes perfect sense, >it is the only legal format of such a frame coming from an ethernet interface. > >As for the third one, it might well be that some device driver misinterprets >the padding (possibly on the output side) and tries to generate 64-bytes >in addition to the headers. Yup. My guess is the first (short) packet was captured on the originating host, so bpf saw it before it hit the wire. The driver should have padded the packet out to 64 bytes on transmission, and the second hop sees the correct (64 - 14 - 4 = 46 byte) payload. I'm not sure what the third system is doing; it looks like it is returning the total packet length, unadjusted for the ethernet headers, which would be a driver bug. However, this is harmless in this case, since the system is using the length from the IP header, not the mbuf length. It isn't clear if the third system is even a FreeBSD box. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Routing problems
Hi!
First off all i have read all the posting from 2001 that might regard my
problem but did'nt find anything at all :(
I'm having some big problems with routing on my FreeBSD 4.4 box (or
atleast i think its the routing..)
The setup is like this :
The firm has 2 different type of nets (the old HP VGANY lan and plain
fast ethernet) and each net has its own /24. On fast ethernet the ip is
192.168.1.0/24 and this net works just fine everutime. But the other net
is way more strange, it has the ip area 192.168.10.0/24 and this only
works if i flush my firewall rules :(
The FreeBSD box has 2 nic's, one for the internal nets and one for thier
adsl connection, the internal nic has ip 192.168.1.1.
And in the rc.conf i have a route add statement and a nic_alias cmd in order
for both nets to access til internet.
But what have i missed in the firewall script file because the second net
does NOT have access to the internet until i flush my rules :(
Any good ideas?
Regards
Dennnis
rc.conf:
ifconfig_ep0="inet 192.168.1.1 netmask 255.255.255.0"
ifconfig_ep1="inet 192.168.2.10 netmask 255.255.255.0"
hostname="jr-data.dk"
linux_enable="NO"
gateway_enable="YES"
defaultrouter="192.168.2.88"
router_flags="-q"
router="routed"
router_enable="YES"
firewall_enable="YES"
firewall_script="/etc/firewall"
sendmail_enable="NO"
inetd_enable="NO"
route add 192.168.10.0 192.168.1.100
saver="blank"
font8x8="cp850-8x8"
font8x14="cp850-8x14"
font8x16="cp850-8x16"
scrnmap="NO"
keyrate="fast"
keymap="danish.cp865"
/etc/firewall
/sbin/natd -interface ep1
fwcmd="/sbin/ipfw"
inet="192.168.1.0"
inet1="192.168.10.0"
imask="255.255.255.0"
iip="192.168.1.1"
#From this computer an on to the net
$fwcmd add 100 pass all from ${iip} to ${inet}:${imask}
$fwcmd add 110 pass all from ${inet}:${imask} to ${iip}
$fwcmd add 120 pass all from ${oip} to ${onet}:${omask}
$fwcmd add 130 pass all from ${onet}:${omask} to ${oip}
$fwcmd add 140 pass all from ${iip} to ${inet1}:${imask}
$fwcmd add 170 pass all from ${inet1}:${imask} to ${iip}
#Hvis der er en forbindelse maa denne bruges
$fwcmd add 200 skipto 1000 tcp from any to any established
#Tillader forbindelse paa de specificerede porte
$fwcmd add 300 skipto 1000 tcp from ${inet}:${imask} to any 23 setup
$fwcmd add 310 skipto 1000 tcp from ${inet}:${imask} to any 53 setup
$fwcmd add 320 skipto 1000 tcp from ${inet}:${imask} to any 80 setup
$fwcmd add 330 skipto 1000 tcp from ${inet}:${imask} to any 25 setup
$fwcmd add 340 skipto 1000 tcp from ${inet}:${imask} to any 110 setup
$fwcmd add 342 skipto 1000 tcp from any 20 to any 3-63000 setup
$fwcmd add 344 skipto 1000 tcp from any 20 to any 1024-4096 setup
$fwcmd add 350 skipto 1000 tcp from ${inet}:${imask} to any 20 setup
$fwcmd add 360 skipto 1000 tcp from ${inet}:${imask} to any 21 setup
$fwcmd add 370 skipto 1000 tcp from ${inet}:${imask} to any 119 setup
$fwcmd add 380 skipto 1000 tcp from ${inet}:${imask} to any 443 setup
$fwcmd add 392 skipto 1000 tcp from ${inet}:${imask} to any 1433 setup
$fwcmd add 390 skipto 1000 tcp from any to any 3389 setup
$fwcmd add 301 skipto 1000 tcp from ${inet1}:${imask} to any 23 setup
$fwcmd add 311 skipto 1000 tcp from ${inet1}:${imask} to any 53 setup
$fwcmd add 321 skipto 1000 tcp from ${inet1}:${imask} to any 80 setup
$fwcmd add 331 skipto 1000 tcp from ${inet1}:${imask} to any 25 setup
$fwcmd add 341 skipto 1000 tcp from ${inet1}:${imask} to any 110 setup
$fwcmd add 351 skipto 1000 tcp from ${inet1}:${imask} to any 20 setup
$fwcmd add 361 skipto 1000 tcp from ${inet1}:${imask} to any 21 setup
$fwcmd add 371 skipto 1000 tcp from ${inet1}:${imask} to any 119 setup
$fwcmd add 381 skipto 1000 tcp from ${inet1}:${imask} to any 443 setup
$fwcmd add 394 skipto 1000 tcp from ${inet1}:${imask} to any 1433 setup
#UDP trafik
$fwcmd add 400 skipto 1000 udp from any 53 to any
$fwcmd add 410 skipto 1000 udp from any to any 53
$fwcmd add 485 skipto 1000 udp from any to any 119
$fwcmd add 486 skipto 1000 udp from any 119 to any
$fwcmd add 487 skipto 1000 udp from any to any 443
$fwcmd add 488 skipto 1000 udp from any 443 to any
$fwcmd add 490 skipto 1000 udp from any 3389 to any
$fwcmd add 495 skipto 1000 udp from any to any 3389
$fwcmd add 498 skipto 1000 udp from any 1433 to any
$fwcmd add 499 skipto 1000 udp from any to any 1433
#icmp
$fwcmd add 500 skipto 1000 icmp from any to any
#Terminalserver
$fwcmd add 600 allow tcp from any to 192.168.1.5 setup
$fwcmd add 601 allow tcp from 192.168.1.5 to any setup
#Stop alt som ikke er skippet til regel 1000
$fwcmd add 900 deny all from any to any
#NAT det som er tilladt af tidligere regler.
$fwcmd add 1000 divert natd all from any to any via ep1
$fwcmd add 1100 pass all from any to any
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Network setup questions
Hi Joao, (vôce é português?) >I don't know much about pptp-client programs merely about the ports >needed >to >be open on a firewall in order to pass it trough. But if you say it >won't >work even with the firewall open, i guess there's not much help I >can >give >you.. No, I opened it up and had the same problem. Could nat be making problems for me? It's configured for my "external" interface wi0 (on the 10.10.2.0 net), should I configure it for the ng0 iface, or for something else? I tried pptp-client, the config script (perl) crashes, the script wants config files in /etc/pptp.d/ while the readme says to put them in /etc/ppp/ppp.conf (neither seems to work). It hangs when run, no log, no info, no connection :-( mpd-netgraph changes terms in the documentation (sometimes server, sometimes peer - the same, right?), nor is it clear to me what is my IP address and what is my peers address, if I need a "pptp self" address at all or not (and if so, which of my addresses is it?). My machine has (at least) 2 IP addresses... One for the LAN, one for the WAN. Also there's the loopback, and devices down that don't currently have addresses, like ppp0. And I'm assigned an IP when (if) I connect successfully via PPTP (and I know the genereal range). Plus I'm supposed to supply the VPN "name", I can't see where that is configured. Nor does the documentation say if one needs a pap.secrets or chap.secrets - all I have is a mpd.secrets, dunno if it's enough... Anyway I feel like I'm just digging myself deeper in this quicksand with each repeated time. Now I've found some doc's on Deja that say you need to run pppd in addition to pptp, one runs over the other. ?!?!? No wonder I'm getting confused ;-) >Anyway about the firewall . In my experience with pptp I had to >open the >following ports.. > >control channel: 1723 tcp & udp > >GRE or GRE over UDP: P:47 or 47 udp > >And because of the client being behind the firewall (in my case) I >had to >add >-pptpalias to my natd parameters.. But since you use the > >firewall >as a client I guess you don't need that anyway. I have no idea. I really need to get an overview as to all this stuff fits together and interoperates >It's not much , but I hope it helps. > >Regards, >Joao Thanks for trying! Regards, Thor _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: kernel backtrace for kern/28844
In message <8BA878388251D311B08200508B449FD10D0E3F4A@BEHDEVEX1>, Rudi Mathijsse n writes: >--- >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0x79c02812 This is caused by a bug in ip_icmp.c relating to the generation of ICMP redirect messages that was fixed just before 4.3-RELEASE. The problem will go away if you upgrade to a more recent release. I can be almost 100% certain that this particular bug is the cause of your crashes because of the virtual address above. The bug caused the two most significant bytes of the mbuf mh_next pointer to get swapped, so a valid address 0xc0792812 got changed to 0x79c02812. It's a pity that not all bugs have such distinctive signatures :-) Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mpd-netgraph log questions
Still struggling with PPTP... Trying to decipher the logfile in order to ask more appropriate questions and get this working. I have these iface's configured at startup: dc0 (home LAN 192.168.128.0) lp0 (? never used) lo0 (loopback) ppp0 (? never used) sl0 (? never used) faith0 (ipv4 -> ipv6) wi0 (ISP WAN 10.10.2.0, internet connection via VPN) When I run mpd I get ng0 as well (netgraph, it seems). I think I've narrowed my problem down to my configuration files. I *think* I'm able to connect with the VPN/PPTP server: Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 627, version 3.3 ([EMAIL PROTECTED] 22:47 18-Nov-2001) [:] load access [access] ppp node is "mpd627-access" [access] using interface ng0 mpd: option "mppc" unknown mpd: option "mppc" unknown [access:access] open [access] IFACE: Open event [access] IPCP: Open event [access] IPCP: state change Initial --> Starting [access] IPCP: LayerStart [access:access] [access] bundle: OPEN event in state CLOSED [access] opening link "access"... [access] link: OPEN event [access] LCP: Open event [access] LCP: state change Initial --> Starting [access] LCP: LayerStart [access] device: OPEN event in state DOWN pptp0: connecting to 10.10.1.1:1723 [access] device is now in state OPENING pptp0: connected to 10.10.1.1:1723 pptp0: attached to connection with 10.10.1.1:1723 pptp0-0: outgoing call connected at 64000 bps [access] PPTP call successful [access] device: UP event in state OPENING [access] device is now in state UP [access] link: UP event [access] link: origination is local [access] LCP: Up event [access] LCP: state change Starting --> Req-Sent [access] LCP: phase shift DEAD --> ESTABLISH [access] LCP: SendConfigReq #1 ( I don't know why it says connected at 64000 bps! Its a pptp node, not a ppp node, isn't it?) However, I never get any further, and the program keeps retrying: [access] LCP: SendConfigReq #3 PROTOCOMP MRU 1500 MAGICNUM c685c33c AUTHPROTO CHAP MSOFT [access] LCP: rec'd Configure Reject #3 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFT so here I'm guessing that something is configured wrong and everything stops, because after about 10 retries I get the following: [access] LCP: not converging [access] LCP: parameter negotiation failed [access] LCP: state change Ack-Sent --> Stopped [access] LCP: LayerFinish [access] device: CLOSE event in state UP pptp0-0: clearing call [access] device is now in state CLOSING [access] device: DOWN event in state CLOSING [access] device is now in state DOWN And then everything starts again. I've checked and double checked my login/password, they are correct (besides, I'm sure a program as comprehensive as this one would say "invalid password" if that was the case - right?) Do I need a chap.secrets file in /etc or /etc/ppp? I assumed all I need is a mpd.conf, mpd.links and mpd.secrets. What am I missing (besides an internet connection :-)? Regards, Thor _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mpd-netgraph configuration files
Still debugging, some questions to verify I have the proper config. FBSD dual homed host/gw for a home LAN dc0 home LAN192.168.128.0/24 wi0 ISP WAN 10.10.0.0/16 IPFW and NAT are running, ipfw is wide open at present, natd running -m -s -dynamic on wi0. Don't know if I need anything else special on nat for PPTP to work. My ISP has a pool of dynamically assignable (DHCP) routable IP's that they assign via a PPTP server at 10.10.1.1. The routable IP's are in the range 213.225.121.0/24 as far as I understand. My config looks like this: # mpd.conf access: new -i ng0 access access set iface idle 0 set iface route default set iface disable on-demand set bundle disable multilink set bundle authname "myreallogin" set bundle password "myrealpassword" set link yes pap set link yes chap set link no mppc set link disable no-orig-auth set ipcp ranges 0.0.0.0/0 10.10.1.1/0 and links like this: # mpd.links access: set link type pptp set pptp mode active set pptp peer 10.10.1.1 set pptp enable originate outcall mpd.secrets has one line, with the same login/password as in mpd.conf I'm a bit unsure as to what values should be in "set ipcp ranges", but I don't seem to get the error message mentioned in the manual so I think it's ok as is. Does this appear at all correct? My ISP knows a bit about Linux (they use it for the PPTP/VPN server, running PoPToP), and said I needed a "name" variable somewhere, at least when connecting from Linux (but not Windows). Should I use the "set link ident" for this? Regards, Thor _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
arp_rtrequest: bad gateway value
Hi,
I'd like to pick some brains before I file a PR.
I've got 4.4-RELEASE running on FreeBSD-alpha with more than one
alias on my network interface. I decided to try out routed, and
started noticing gobs and gobs of messages:
Nov 15 11:38:10 tick /kernel: arp_rtrequest: bad gateway value
Nov 15 11:43:10 tick /kernel: arp_rtrequest: bad gateway value
Nov 15 11:47:59 tick /kernel: arp_rtrequest: bad gateway value
Nov 15 11:58:02 tick last message repeated 2 times
Nov 15 12:08:10 tick last message repeated 2 times
Nov 15 12:18:10 tick last message repeated 2 times
It turns out, this is caused by a bad arp entry:
17:21:33{{ttyq8}pherman@tick}~//> arp -a
ns1.sc.omation.com (192.168.128.1) at 0:0:0:0:0:0 permanent [ethernet] rt=200
tick.sc.omation.com (192.168.128.2) at 0:60:97:6e:6e:92 permanent [ethernet]
[...etc...]
Trying to delete the entry gives me "cannot locate 192.168.128.1",
probably because the kernel thinks it doesn't exist becase the
MAC addr == NULL... ...perhaps (?) Whatever, it shouldn't be there
in the first place.
So, I've narrowed this down to when routed it writes RTM_CHANGE
of type RTF_HOST in sbin/routed/table.c:725
if (mask == HOST_MASK) {
w.w_rtm.rtm_flags |= RTF_HOST;
w.w_rtm.rtm_msglen -= sizeof(w.w_mask);
} else {
w.w_rtm.rtm_addrs |= RTA_NETMASK;
w.w_mask.sin_addr.s_addr = htonl(mask);
Something is going haywire (64bit issues?) because when I change
this to
if (mask == HOST_MASK && 0) {
it works fine, but I'm sure I'm breaking something. :-) There
*is* a sizeof(long) just after it on line 734 which should be a
sizeof(u_int32_t), but that doesn't change anything in this case.
This obviously works fine on 32-bit architectures, so I'm thinking
it's some kind of alignment or sizeof problem, but I don't see it.
Can anyone comment on this?
-Paul.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Garbage tacked onto end of packet
http://lcamtuf.coredump.cx/mobp/ See Exhibit 5. Is this a known bug? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Garbage tacked onto end of packet
[Bcc to Przemyslaw Frasunek who submitted the example in case he can tell what hardware was involved] On Wed, Nov 21, 2001 at 02:36:56PM +0100, Dag-Erling Smorgrav wrote: > http://lcamtuf.coredump.cx/mobp/ > > See Exhibit 5. Is this a known bug? Looks more like one or more bugs in a specific device driver, tcpdump or bpf. Here we have a short IP packet (44 bytes) which is later shown as having 46 and then 64 bytes. On the wire, ethernet frames are supposed to have at least 64 bytes (including CRC ?) which is exactly 14+46+4 -- so the second example makes perfect sense, it is the only legal format of such a frame coming from an ethernet interface. As for the third one, it might well be that some device driver misinterprets the padding (possibly on the output side) and tries to generate 64-bytes in addition to the headers. cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
