Re: Some routes no longer getting flagged with 'GATEWAY' in fbsd >=8

[Brian Somers]

Also relevant is this patch

http://patchwork.diac24.net/patch/494/mbox/

I guess it seems like more of a workaround than a fix though.


On Jun 17, 2013, at 12:18 PM, "Li, Qing"  wrote:

> Hi,
> 
> I tried to keep the route messages to be legacy compatible due to reported 
> breakage at the time. Let me revisit the code and get back to you.
> 
> I haven't run the quagga code for years, so please don't mind me request
> some information from you offline.
> 
> --Qing
> 
> 
> 
> From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf 
> of Mack Nagashima [free...@mackn.org]
> Sent: Monday, June 17, 2013 11:44 AM
> To: freebsd-net@freebsd.org
> Subject: Some routes no longer getting flagged with 'GATEWAY' in fbsd >=8
> 
> we're in the process of upgrading from fbsd 7 to 9 and noticed a change
> in behavior that might be problematic for us.
> 
> We use quagga to establish bgp sessions with a router.  We have it set
> to redistribute kernel routes.
> Zebra seems to drop anything that doesn't have the 'GATEWAY' flag set on
> a route.
> 
> Prior to fbsd8 this wasn't a problem.  Doing something like the
> following worked fine in fbsd7:
> 
> ifconfig em0 inet 192.168.100.1/24
> ifconfig lo0 inet 192.168.100.100/24 alias
> route add -nostatic 192.168.100.100/32 192.168.100.1
> 
> in fbsd7 this would yield a route with the flags  according
> to RTM_GET.
> in fbsd8+ the same would yield a route with  without the GATEWAY flag.
> 
> However the RTM_ADD for the 'route add' comes in with 
> on fbsd8+ so quagga does add if it's up before the route gets added but
> starting quagga after the route is added ignores it since it's missing
> the GATEWAY flag once in the routing table.  (route delete also fails to
> propagate to quagga since the GATEWAY flag is missing)
> 
> I assume this is all due to the networking overhaul in fbsd8 and perhaps
> it no longer flags any route who's gateway is bound to ANY interface on
> the box as a gateway.
> 
> So the ultimate question is..  is there a way to get the legacy behavior
> and get them flagged with GATEWAY so zebra will see them or a better
> solution with the way networking now works...  (i noticed that issuing a
> 'route change' of an existing route with the GATEWAY flag set seems to
> work as it doesn't drop the flag when the gateway changes under it...)
> 
> Thanks in advance!
> 
> -mackn
> 

--
Brian Somers  
Don't _EVER_ lose your sense of humour !   

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Removing support for FreeBSD 2.x in PPP

[Brian Somers]

There are certainly no objections from me.

On Jul 1, 2013, at 3:35 PM, Robert Millan  wrote:

> Hi,
> 
> Is there any concern if the arcane FreeBSD 2.x build logic is removed from 
> PPP?
> 
> These ifdefs are currently being hit when building on GNU/kFreeBSD
> (because of __FreeBSD__ value being undefined, i.e. 0).
> 
> I guess one could add even more ifdef logic could be added to handle
> that, but it seems a bit pointless since 2.x is such an old release
> series.
> 
> If there is no objection I will check in the attached patch.
> 
> --
> Robert Millan
> 

--
Brian Somers  
Don't _EVER_ lose your sense of humour !   

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: strange ping on local address

[Brian Somers]

On Fri, Jul 22, 2011 at 02:54:11PM +0700, Rashid N. Achilov wrote:
> When I try to ping local interface - ping missed! When I try to ping this 
> interface with -S key (specified the same address) - working. What's a bug? 
> In RELENG_7 worked.
> 
> local interface on box:
> em0: flags=8943 metric 0 mtu 
> 1500
> options=219b
> ether 00:xx:xx:xx:xx:xx
> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
> media: Ethernet autoselect (100baseTX )
> status: active
> 
> ping ordinary:
> master:[root] 105>ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> ^C
> --- 192.168.1.1 ping statistics ---
> 2 packets transmitted, 0 packets received, 100.0% packet loss
> 
> ping with -S key:
> master:[root] 106>ping -S 192.168.1.1 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) from 192.168.1.1: 56 data bytes
> 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.022 ms
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.030 ms
> ^C
> --- 192.168.1.1 ping statistics ---
> 2 packets transmitted, 2 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.022/0.026/0.030/0.004 ms
> 
> master:[root] 103>uname -a
> FreeBSD master.askd.ru 8.2-STABLE FreeBSD 8.2-STABLE #1: Fri Jul 15 18:23:18
> NOVST 2011 r...@master-new.askd.gmbh:/usr/obj/usr/src/sys/Master  i386
> 
> What's a terrible? I'm understand, that ping "itself" is rarely situation, 
> but 
> it worked in 7.x! 

What happens if you "route delete 192.168.1.1" and then try the ping
without using -S?

-- 
Brian Somers  
Don't _EVER_ lose your sense of humour !   
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Problem with PPP, tcpmssd and routing socket messages

[Brian Somers]

A patch'd be good :-)

Cheers.

> Hi Brian,
> 
> 
> > > The funny thing is that if I do a ifconfig tun0 mtu 1333, I see
> > the proper
> > > RTM_IFINFO messages...
> >
> > ppp sets the interface mtu using TUNSIFINFO rather than SIOCSIFMTU.
> > See src/usr.sbin/ppp/tun.c.
> >
> 
> OK now I see it... This seems to be the culprit. I guess that this ioctl as
> well as possibly TUNSIFMODE should generate the proper routing socket
> messages (RTM_IFINFO). Do you want me to do that and send you a patch, or do
> you want to handle it yourself ?
> 
> 
> Patrick.

-- 
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

Re: patch to cleanup inflight desciptor handling.

[Brian Somers]

> Not a lot of people are familiar with fd passing so I'll give
> a short description:
> 
>   By using AF_UNIX sockets between processes, a process can use
>   sendmsg() to send a filedescriptor through the socket where the
>   other process will do a recvmsg() to pickup the descriptor.
> 
> The "problem" is that if a descriptor is in transit/inflight
> and the sending process closes the file, it still needs to
> remain open for the recipient.
> 
> What can happen is:
> 
> process A: sendmsg(descriptor)
> process A: exit
> process B: exit
> 
> without the garbage collection we'd have leaked a file descriptor
> inside the kernel.
[.]

Hmm, the last time i looked at this, I believe the whole thing was 
dealt with by not increasing the file descriptor reference count 
when it was put in the message header.  If process A closed the 
descriptor before process B actually recvmsg()d it, it would be 
EBADF.  The recvmsg() actually incremented the reference count.

I always assumed that this was a result of not wanting to have any 
funny garbage collecting code ?

Of course looking at the code now, it increases fp->f_count in 
unp_internalize(), so maybe I was on drugs then

Assuming I wasn't on drugs (maybe the behaviour was changed - cvs 
annotate suggests some activity around March 9, but that was the 
file*/int alignment stuff), I think it would be valid to go back 
to the old behaviour (not increasing f_count and letting the original 
owner actually close the descriptor while f_msgcount != 0).

Does any of this make sense ?  Or am I just describing a different 
case (where process B doesn't exit) ?

> -- 
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> "I have the heart of a child; I keep it in a jar on my desk."

-- 
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

Re: patch to cleanup inflight desciptor handling.

[Brian Somers]

> Brian Somers <[EMAIL PROTECTED]> wrote:
> >
> >Hmm, the last time i looked at this, I believe the whole thing was 
> >dealt with by not increasing the file descriptor reference count 
> >when it was put in the message header.  If process A closed the 
> >descriptor before process B actually recvmsg()d it, it would be 
> >EBADF.  The recvmsg() actually incremented the reference count.
> 
> But it has always been documented behaviour that the receiving process
> gets a valid descriptor even if the sender closes it directly after
> sendmsging it. If this was not the case then descriptor handoff would
> require an "ok" reply from the receiving process before the sender
> could close it, which is a pain.
> 
> Hmm, the only references for this I can think of are Stevens and the
> red & black daemon books, but I'm sure I've read a good discussion of
> it somewhere else.

I've just looked back through my archives... the problem I'm thinking 
of was a different problem - where the descriptor passed was the only 
descriptor open for a tty whose pgrp was that of process A.  A passed 
the descriptor to B and then exited at which point the tty 
(correctly) revoked all it's remaining descriptors (the one en-route 
or in process B).

There's no way to avoid this - except by having A fork(), the child 
close the descriptor and continue where it left off and the parent 
pause() waiting for a signal from B to tell it that it's finished 
with that tty.

This is why I implemented ``enable keep-session'' :-)

> Tony.
> -- 
> f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
> "And remember my friend, future events such
> as these will affect you in the future."

Cheers.

-- 
Brian <[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

Re: PPPoE w/ nat auto fragmentation hack?

[Brian Somers]

> 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.
> 
> Right on Brian! And thanks to Ruslan and Julian. Great job guys.

And thank you for taking the time to report things as working :-)

> - Original Message -
> From: Brian Somers <[EMAIL PROTECTED]>
> To: Renaud Waldura <[EMAIL PROTECTED]>
> Cc: Brian Somers <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Thursday, November 16, 2000 1:37 PM
> Subject: Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port)
> 
> 
> > > > ppp will run programs as the user id that invoked ppp rather than
> > > > using the effective user id (ie, it runs things as *you*, not *root*).
> > >
> > > Mmm-mmh. In my case, since ppp is started at boot time, the only user
> that
> > > ever invokes it is root, hence the tcpmssd thingy is run as root. As
> > > confirmed by the multiple "ps" I ran: euid == ruid == svguid == 0.
> > >
> > >
> > > > A good ``first step'' is to run
> > > >   ! sh -c "/usr/local/bin/tcpmssd -p 12345 -i INTERFACE >/tmp/log
> 2>&1"
> > > > so that you can get to see any error messages - ppp redirects I/O to
> > >
> > > Yup, tried that, here's what I get:
> > >
> > >  start ***
> > > Wed Nov 15 13:30:12 PST 2000
> > > id says: uid=0(root) gid=0(wheel) groups=0(wheel)
> > > HOME=/
> > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
> > > 01001 divert 1234 tcp from any to any out xmit tun0 setup
> > >
> > > The rule gets inserted, tcpmssd runs as root, and I feel like a dummy.
> Any
> > > other ideas?
> > >
> > > Thanks for the help Brian,
> >
> > I'm not sure what the problem could be - can you confirm that
> > everything's seen if you divert everything ?

-- 
Brian <[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

Re: multiple MP PPP from one box - is it possible?

[Brian Somers]

> I have 2 lines to direction A and 2 lines to direction B,
> and like to use multilink PPP on both directions 
> from one box simultaneously 
> (my box is FreeBSD 4.0-R, boxes A and B are also F4.0-R)
> I have tried to use user PPP ver 2.26
> but didn"t succeed, is it possible? or I"m doing smth wrong?

An MP endpoint is identified by it's endpoint discriminator and 
authentication name.  If the peers aren't using either you'll get 
the two confused.

You need to either authenticate (``set authname'') as a different 
user on each of your peers or ``set enddisc something'' on each.  
``set enddisc MAC'' at the beginning of the default profile  is a 
good solution if you've got NICs in the boxes.

> --
> GVF


-- 
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

Re: Routes and tunnels

[Brian Somers]

If you mean a packet destined for the source address of the 
POINTOPOINT link, then yes, this is intentional.  If you want to be 
able to ping the local end you'll need a route on lo.

> Hi
> 
> I don't know if this is intentional or a bug, but if ifconfig is used to
> configure a point to point device, such as 'tun' or the newer 'gif' devices,
> then the kernel insists on installing a route where the destination is the
> end point of the tunnel, the gateway is the source of the tunnel and the
> interface is the device itself. I have checked this in version 3.2+KAME,
> what I a using, and also on version 4.1. The effect of the above is that the
> packet that uses the tunnel will never appear on the wire.
> 
> Here is an output
> 
> the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1
> the_swamp# netstat -rnf inet
> Routing tables
> 
> Internet:
> DestinationGatewayFlags  Netif Expire
> default132.146.115.1  UGSc10 fxp1
> 127.0.0.1  127.0.0.1  UH  04  lo0
> 132.145.113.1  132.146.115.164UH  00 gif0
> 132.146.115/24 link#2 UC  00 fxp1 =>
> 132.146.115.1  0:30:19:9a:e4:71   UHLW20 fxp1460
> 
> I am also interested in using gated with point to point tunnels, but gated
> also insists on doing the above for point to point links.
> 
> I thank you in advance for any advice you may have.
> 
> Parminder Mudhar
> __
> [EMAIL PROTECTED]

-- 
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

Re: PPP - CHAP failure after CHAP success???

[Brian Somers]

Hmm,

I can't see how this can happen without any previous log lines saying 
that a chap packet has been received.

If this is repeatable, can you try doing a ``show timer'' right after 
the SUCCESS response has been sent ?  If the radius timer wasn't 
cleared properly this might result, but I can't see how that could 
happen...

> On a recently cvsup'd machine (4.2-S as of two days ago), incoming PPP
> w/CHAP via RADIUS has suddenly broken.  Basically, RADIUS OK's the
> connection, addr info is transferred & approved, everything looks normal,
> until after the log line listing myaddr and hisaddr - why is it doing
> CHAP again, and what happened to my RADIUS server?  README.changes diffs
> only mentioned MSCHAPv2 and MPPE changes - disabled both of those, but it
> doesn't make any difference.  
> 
> --mike
> 
> 
> Feb  2 16:06:56 rimmer ppp[320]: tun1: Phase: bundle: Authenticate 
> Feb  2 16:06:56 rimmer ppp[320]: tun1: Phase: deflink: his = none, mine =
> CHAP 0x05 
> Feb  2 16:06:56 rimmer ppp[320]: tun1: Phase: Chap Output: CHALLENGE 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Input: RESPONSE (16
> bytes from argos) 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: Radius: Request sent 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: Radius: ACCEPT received 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: MTU 1500 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: VJ enabled 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: IP 10.99.1.6 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: Netmask
> 255.255.255.252 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Output: SUCCESS 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Warning: 10.99.1.6: Cannot
> determine ethernet address for proxy ARP 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: lcp -> open 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: bundle: Network 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP: FSM: Using "deflink" as a
> transport 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Initial
> --> Closed 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: LayerStart. 
> Feb  2 16:06:57 rimmer
> ppp[320]: tun1: IPCP: deflink: SendConfigReq(1) state = Closed 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP:  IPADDR[6]  10.129.1.2 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP:  COMPPROTO[6]  16 VJ slots
> with slot compression 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Closed
> --> Req-Sent 
> Feb  2 16:06:57 rimmer
> ppp[320]: tun1: IPCP: deflink: RecvConfigReq(3) state = Req-Sent 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP:  IPADDR[6]  10.99.1.6 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP:  COMPPROTO[6]  16 VJ slots
> with slot compression 
> Feb  2 16:06:57 rimmer
> ppp[320]: tun1: IPCP: deflink: SendConfigAck(3) state = Req-Sent 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP:  IPADDR[6]  10.99.1.6 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP:  COMPPROTO[6]  16 VJ slots
> with slot compression 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change
> Req-Sent --> Ack-Sent 
> Feb  2 16:06:57 rimmer
> ppp[320]: tun1: IPCP: deflink: RecvConfigAck(1) state = Ack-Sent 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change
> Ack-Sent --> Opened 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: LayerUp. 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: IPCP: myaddr 10.129.1.2 hisaddr =
> 10.99.1.6 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Warning: 10.99.1.6: Cannot
> determine ethernet address for proxy ARP 
> 
> ...new stuff starts here - these lines never showed up before.
> 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: radius: No RADIUS servers
> specified 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Output: FAILURE 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: open -> lcp 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: LayerDown 
> Feb  2 16:06:57 rimmer
> ppp[320]: tun1: LCP: deflink: SendTerminateReq(3) state = Opened 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Opened
> --> Closing 
> Feb  2 16:06:57 rimmer
> ppp[320]: tun1: LCP: deflink: RecvTerminateReq(4) state = Closing 
> Feb  2 16:06:57 rimmer
> ppp[320]: tun1: LCP: deflink: SendTerminateAck(4) state = Closing 
> Feb  2 16:06:57 rimmer
> ppp[320]: tun1: LCP: deflink: RecvTerminateAck(3) state = Closing 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: LayerFinish 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Closing
> --> Closed 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Closed
> --> Initial 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Warning: deflink: Unable to set
> physical to speed 0 
> Feb  2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: Disconnected! 

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAI

Re: PPP - CHAP failure after CHAP success???

[Brian Somers]

Hi,

> > I can't see how this can happen without any previous log lines saying 
> > that a chap packet has been received.
> > 
> > If this is repeatable, can you try doing a ``show timer'' right after 
> > the SUCCESS response has been sent ?  If the radius timer wasn't 
> > cleared properly this might result, but I can't see how that could 
> > happen...
> 
> Hmm...  Repeatable every time on the machine in question.  (Time passes
> while I configure the a similar on a completely different set of
> boxes.)  Yup - repeatable on another machine as well.
> 
> Two machines - core-1 and twikki.  Twikki is receiving the call.
> 
> I don't have the muscle trigger upgrade in my finger yet to be able to hit
> return right when the SUCCESS rsp comes through (goes by way too fast),
> but I did turn on timer debugging for these logs -- maybe it'll help.  If
> there's some way to trigger a "show timer" in the source at a certain
> point, I'd be happy to try that...
> 
> Thanks - Mike
[.]

Err ok, on reflection that was a rather tricky thing to ask you to 
do...  Sorry :-/

I think I've figured out the problem though... can you try the latest 
version of ppp - should be available via 
http://www.Awfulhak.org/ppp.html RSN (the 010204 archive) if you 
don't get -current.

I think you're just missing an acct line in your radius config file.  
The bug in ppp is that it treats the accounting failure as something 
it needs to send an authentication failure about
-- 
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

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

[Brian Somers]

> 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

It didn't make 4.2 - it was MFC'd on December 18 :-(

> -- 
>   __--_|\  Julian Elischer
>  /   \ [EMAIL PROTECTED]
> (   OZ) World tour 2000-2001
> ---> X_.---._/  
> v

-- 
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

Re: ISDN question.

[Brian Somers]

> Hello.
> I would like to find or may be somebody can give me some additional
> instruction how to run ISDN line. I installed in kernel Fritz!Card and
> read in /etc/isdn examples but can't understand how to begin this run.
> Thank you very much for any help.

Have you looked at /usr/share/examples/ppp/*isdn* ?
-- 
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

Re: PPPoE

[Brian Somers]

If you upgrade to the latest version of ppp(8) (you can get an 
archive from http://www.Awfulhak.org/ppp.html) the problem should go 
away.  ppp(8) now fixes this stuff itself (look for mssfixup in the 
man page).

> Okay, I feel stupid...
> 
> I've got a 4.2 Release box set up as a firewall with some clients behind it.
> I'm using my BSD box as PPPoE client.  My problem is the "win clients can't
> get to certain web sites" issue, I've verified by sending large ping packet
> from outside and it gets lost between tun0 and internal interface.  I've
> tried the tcpmssd.rc stuff, but have not been able to get it working
> properly (all packets hit the divert rule, but drop somewhere inside).  Can
> anyone suggest anything?
> 
> Here are various details...
> 4.2 release
> 
> options NETGRAPH
> options NETGRAPH_ETHER
> options NETGRAPH_PPPOE
> options NETGRAPH_SOCKET
> In kernel
> 
> myprofile:
>  set device PPPoE:fxp0
>  set mru 1492
>  set mtu 1492
>  set authname XX
>  set authkey XX
>  set log Phase tun command
>  set dial
>  set login
>  set ifaddr /net /net
>  add default HISADDR
> In ppp.conf
> 
> network_interfaces="auto"
> ifconfig_fxp0="up"
> ppp_enable="YES"
> ppp_mode="dedicated"
> ppp_nat="NO"
> ppp_profile="myprofile"
> ifconfig_fxp1="inet   netmask "
> ifconfig_tun0="inet  0.0.0.0 netmask "
> 
> 
> Thanks in advance for ANY help!!!

-- 
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

Re: MAXHOSTNAMELEN redux

[Brian Somers]

Just some ramblings

I find this a bit odd.  I concluded recently that NAME_MAX was the 
odd-one-out WRT not having the NUL only because it is the maximum 
size of a *component* of a path.  When the value is used, it makes 
sense to talk in terms of the without-NUL value.

This change seems to make it even more likely that people will forget 
whether MUMBLE_MAX includes the NUL or not.

If I were defining this sort of thing (hah!), I'd have *_LEN as 
definitions without NULs and *_SIZE as definitions with the NUL.  
*_MAX seems to be used more commonly as the maximum number of 
something (ARG_MAX, CHILD_MAX), so NAME_MAX seems to be a misspelt 
version of NAME_CHARS_MAX ditto for PATH_MAX and probably others.

Ok, I'm done :-)

> My bug report against the current POSIX draft was accepted.  For the
> record, here are the changes being made.  (``The indicated line'' is
> referring to a line in the definition of gethostname() where the
> length of the buffer was previously defined to be 256, including the
> terminating null.  The excluding-null semantics were chosen for
> parallel construction with {NAME_MAX} and similar constants.
> 
>  At the indicated line, for 255 substitute {HOST_NAME_MAX}.
>  At XBD page 261 () before line 8966 insert:
> 
>{HOST_NAME_MAX}
>  Maximum length of a host name (not including the terminating
>  null) as returned from the gethostname() function.
>  Minimum acceptable value: {_POSIX_HOST_NAME_MAX}
> 
>  Before line 9183, insert:
> 
>{_POSIX_HOST_NAME_MAX}
>  Maximum length of a host name (not including the terminating
>  null) as returned from the gethostname() function.
>  Value: 255
> 
>  At XBD page 424 () before line 14818 insert:
> 
>_SC_HOST_NAME_MAX
> 
>  At XSH page 1982 (sysconf()) before line 45530 insert:
> 
>{HOST_NAME_MAX}   _SC_HOST_NAME_MAX
> 
>  I include the last two changes for completeness only; I do not
>  believe that applications are likely to use the sysconf() interface
>  for this purpose.
> 
> -GAWollman

-- 
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

Re: Changing UDP select() behavior

[Brian Somers]

> Hi,
> 
> I'm wondering if anyone has ever considered modifying the UDP behavior with
> regard to selecting:
> 
> Currently, writing to a UDP socket either enqueues packets in the interface
> queue (returning success), or drops them on the floor (returning ENOBUFS)
> if the queue is full. Selecting-to-write on a UDP socket always succeeds,
> never blocks.
> 
> I'm considering changing this, so that a select-to-write on a UDP socket
> will block until queue space becomes available. (I don't think this would
> violate UDP semantics, but is a big enough change to warrant a new sockopt
> to enable it.)
> 
> Has this been considered/implemented in any OS? Does anyone see any serious
> problems with it? Feedback greatly appreciated!

This'd be nice if it could be made to work.  I guess the problem is 
that you don't actually know if a write() will succeed 'till you try 
it (and try to allocate an mbuf).

Having said this, it would be nice if it was possible to pre-allocate 
(a small number of) mbufs for a pipe() or socketpair(), giving a 
reliable SOCK_DGRAM file-descriptor based ipc mechanism.

> Lars
> -- 
> Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute
> http://www.isi.edu/larse/University of Southern California

-- 
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

Re: user-ppp problems

[Brian Somers]

> Hello,
> 
> Some days ago I began to suffer strange problems with user-ppp
> while trying to connect with one specific ISP. For example,
> sometimes the connection fails to establish and the following
> messages are logged:
> 
> ...
> tun0: Phase: bundle: Authenticate 
> tun0: Phase: deflink: his = CHAP 0x05, mine = none 
> tun0: Phase: Chap Input: CHALLENGE (16 bytes from AccEuskaltel) 
> tun0: Phase: Chap Output: RESPONSE (**) 
> tun0: LCP: deflink: RecvEchoRequest(1) state = Opened 
> tun0: LCP: deflink: SendEchoReply(1) state = Opened 
> tun0: IPCP: deflink: Error: Unexpected IPCP in phase Authenticate (ignored) 
> last message repeated 3 times
> tun0: LCP: deflink: RecvEchoRequest(2) state = Opened 
> tun0: LCP: deflink: SendEchoReply(2) state = Opened 
> tun0: IPCP: deflink: Error: Unexpected IPCP in phase Authenticate (ignored) 
> last message repeated 3 times
> tun0: LCP: deflink: RecvEchoRequest(3) state = Opened 
> tun0: LCP: deflink: SendEchoReply(3) state = Opened 
> tun0: LCP: deflink: RecvEchoRequest(4) state = Opened 
> tun0: LCP: deflink: SendEchoReply(4) state = Opened 
> ...

Your chap response isn't getting a success or failure reply, so ppp 
is still in the ``authenticate'' phase -- it's ignoring the IPCP 
packets sent by the peer.  I'm not sure why the peer isn't sending 
the success/failure message.

> Also, I am wondering about the LCP "RecvEchoRequest" and "SendEchoReply"
> messages. Even when the connection is succesfully established, they
> keep appearing all the time, _only_ with this specific ISP. I thought
> that they could be related to LQR, but I disabled and denied LQR in
> ppp.conf to no avail.

Echo requests must be replied to (well, duplicate echo requests must 
be replied to, but ppp(8) always replies).

> I updated the machine to 4.3-RC a few days ago, so that I borrowed
> /usr/sbin/ppp from other machine still running 4.2-RELEASE (the compat4x
> libraries are installed) and something different happenned, indeed:
> while using 4.2R's ppp, I got these messages after the connection
> was established:
> 
> ...
> tun0: Error: ip_Input: deflink: wrote 52, got Address family not supported by 
>protocol family 
> tun0: Error: ip_Input: deflink: wrote 532, got Address family not supported by 
>protocol family 
> last message repeated 3 times
> tun0: Error: ip_Input: deflink: wrote 412, got Address family not supported by 
>protocol family 
> tun0: Error: ip_Input: deflink: wrote 532, got Address family not supported by 
>protocol family 
> tun0: Error: ip_Input: deflink: wrote 532, got Address family not supported by 
>protocol family 
> ...
> 
> The IPCP negotiation succeeds. However, a ping to the other end of the P-P
> link does not work. OTOH, the "RecvEchoRequest" and "SendEchoReply"
> messages are still being logged.

Sounds like the tun interface is in 
I-want-an-address-family-on-the-front-of-packets mode.  
Unfortunately, later kernels don't reset this flag when the tun 
device is closed, so older versions of ppp won't work on an interface 
that a newer version of ppp has been run on.  You could try using 
something like ``ppp -unit 100 blah'' to get around the problem 
(assuming the old version of ppp is new enough to understand -unit).

> I suspect that something was broken in the ISP, so I would like to
> be able to diagnose this problem before calling to their "support"
> people (they don't know that there are other OS apart from Win**ws).
> 
> Any ideas?
> 
> [I am sending attached the full log of a failed connection]
> 
> -- JMA
> ** Jose M. Alcaide  //  [EMAIL PROTECTED]  //  [EMAIL PROTECTED] **
> ** "Beware of Programmers who carry screwdrivers" --  Leonard Brandwein **
[.]
-- 
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

Re: NEEDED: Source code (C or C++) for fetching MAC Address ?

[Brian Somers]

> Hi,
> 
> I need source code for fetching MAC address on a FreeBSD 4.2/PC/Ethernet
> platform.
> 
> Where can I find it ?

Have a look at src/usr.sbin/ppp/arp.c - get_ether_addr().

> Thanks in advance.

-- 
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

Re: VPN tunnel with DHCP ...

[Brian Somers]

> > 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).

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).

> --
> matt Emmerton

-- 
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

Re: VPN tunnel with DHCP ...

[Brian Somers]

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

But of course :-)  You can even do NAT in this scenario if required - 
as the NAT will happen before the data is encapsulated in the tcp stream 
that ipsec's policies are mangling.

> --
> Matt Emmerton

-- 
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

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

[Brian Somers]

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

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

[Brian Somers]

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

Re: gateway+multi-PPPoE

[Brian Somers]

> 
> Hi!
> 
>   I'm triyng to set-up a Gateway that will use 3 different PPPoE (to 
> the same provider) adsl connection (3 modem , 3 account),  to 
> distribute it back to a soho network.  In instance to get the more 
> bandwith possible.
> 
>  I've been able to set-up the gateway with one modem by using netgraph 
> and PPP. 
> 
> I tought that using mpd would allow me to to get the maximun of these 
> three connections.

ppp should do that too.

> It seem to work well on the gateway.  But the rest of the network is 
> dead (the gate way see everybody and vice versa) but station dont see 
> the net.   
> 
> If somebody have any idea how to make that thing work it will be a 
> great help.

You don't describe exactly how you've got things set up.  Are you 
using Multi-link ppp over PPPoE links ?  If so, you'll need a very 
co-operative provider to sit at the other end.

If you're setting up 3 distinct PPPoE links and then running a 4th 
ppp session using multi-link with (say) UDP links that talk accross 
each of your PPPoE setups to a remote server which demuxes them (by 
running a similar multi-link ppp setup), then you should be able to 
get this working :0)

Feel free to post your configuration and I can see if it makes sense 
to me.

> P.S. I try that solution, if there's other who work better, please tell 
> me .
> thanks
> 
> Nicolas Beauchesne
> [EMAIL PROTECTED] 

-- 
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

Re: how to filter out igmp spam on a ppp -nat dialup?

[Brian Somers]

> this traffic is holding my ppp connection open
> for hours at a time, is there any way to filter 
> this out
> 
> I tried adding `set filter in  0 deny igmp`
> to my ppp.conf config but then I couldn't do external
> DNS.

Try

  set filter alive 0 deny igmp
  set filter alive 1 permit 0 0

Maybe the DNS problem was caused by not having a final permit rule 
(falling off the end of the filter set is the same as a deny).

[.]
> -- 
> Greg Moncreaff
> [EMAIL PROTECTED]
> Marlborough, MA;
> USA

-- 
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

Re: Start on-demand PPP from remote telephone

[Brian Somers]

Last time I looked, mgetty was capable of doing stuff with dtmf 
tones.  I think you need to use the vgetty program rather than mgetty 
(both are installed when you install the port), but that's all I 
remember.

> I have a FreeBSD 4.3 IPFilter 3.4.17 based firewall/gateway
> system at home that uses an on-demand PPP connection to my
> ISP via Hayes type 56k modem.
> 
> I would like to be able to call via telephone my home number
> from a remote location and have getty/mgetty? then start a
> PPP connection to my ISP after detecting the "RING" so I can
> SSH into my home system.
> 
> Searching the web finds lots of PPP info, but I have been
> unable to locate this situation.
> 
> Thanks in advance
> 
> Stephen Hilton
> [EMAIL PROTECTED]

-- 
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

Re: default route disappears on address changes for interface.

[Brian Somers]

ifconfig(8) deletes and re-adds the given address.  When the delete 
happens, the route (now) disappears.

IMHO, ifconfig(8) should be smart enough to optimise out no-ops.

> on FreeBSD 4.3-STABLE #1: Thu May 24 13:03:35 BST 2001
> 
> Is it now standard/expected behaviour that default routes
> disappear on an IP address change even within the same netmask
> or even to the same address if the default route is on that
> interface?
> 
> Say I've got the following setup.
> 
> ifconfig ep0 inet 10.0.0.1 netmask 255.255.255.0
> route add default 10.0.0.254
> 
> then i do 
> 
> ifconfig ep0 inet 10.0.0.2  (or even 10.0.0.1)
> 
> suddenly my default route disappears. Is this expected
> behaviour and has this always been the case? I'm pretty
> sure it wasn't.
> 
> Thanks,
> Mark Blackman

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: [patch] supports 'protoX' notation for all IP protocol numbers

[Brian Somers]

Hi,

I'll look at merging this into my development sources.  I've been 
working on abstracting NCP addresses so that IP6 functionality can be 
developed on ppp more easily.

I'll hopefully have something worth committing in the next few days.

Thanks.

> I've sent following patch;
> 
> matusita> This patch does teach ppp(8) about 'ipv6' protocol (protocol
> matusita> number 41) to filter.  This patch also fixes
> matusita> not-initializing 'f_dstop' variable for other protocols.
> 
> but some other guys says that "why not you make ppp to specify
> protocol number directly, just like 'set filter out 0 permit 41' or whatever?"
> It's good suggestion to me, so I've update my patch to support this.
> 
> ***
> 
> This patch allows to users to specify any IP protocol number in their
> filter ruleset. For example, if you want to pass incoming L2TP
> (protocol number 115) packet,
> 
>   set filter in 0 permit proto115
> 
> where 'proto115' means 'protocol number 115'. Since ppp(8) doesn't
> know L2TP or any ppp(8) unsupported protocol, you can only specify
> src/dst addresses to a filter rule of these unknown protocols
> (specifying 'port' or whatever will not work).
> 
> I hope this patch works as expected (I've tested with my ADSL line and
> it seems working) and doesn't hurt any existing features, but if you
> have a time, please review this patch.
> 
> -- -
> Makoto `MAR' MATSUSHITA
[patch deleted]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: interface cloning MFC

[Brian Somers]

> I plan to MFC the network interface cloning support and the gif
> modularization early next week unless someone has objections.  I'd like
> to get it in before the code slush and since I'll be leaving for a week
> on the 31st, that means sometime early to mid next week to allow for any
> bug reports.  I don't really expect any problems.

Good stuff.

> A diff is available at:
> 
> http://people.freebsd.org/~brooks/patches/gif-stable.diff

You forgot:

Index: LINT
===
RCS file: /home/ncvs/src/sys/i386/conf/Attic/LINT,v
retrieving revision 1.749.2.64
diff -u -r1.749.2.64 LINT
--- LINT2001/06/29 21:14:24 1.749.2.64
+++ LINT2001/07/20 19:35:42
@@ -509,7 +509,7 @@
 optionsETHER_SNAP  # enable Ethernet_802.2/SNAP frame
 
 # for IPv6
-pseudo-device  gif 4   #IPv6 and IPv4 tunneling
+pseudo-device  gif #IPv6 and IPv4 tunneling
 pseudo-device  faith   1   #for IPv6 and IPv4 translation
 pseudo-device  stf #6to4 IPv6 over IPv4 encapsulation
 

I'm just rebuilding the world now :)  I'll let you know how I get on. 
Thanks for your work.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: interface cloning MFC

[Brian Somers]

> I plan to MFC the network interface cloning support and the gif
> modularization early next week unless someone has objections.  I'd like
> to get it in before the code slush and since I'll be leaving for a week
> on the 31st, that means sometime early to mid next week to allow for any
> bug reports.  I don't really expect any problems.
> 
> A diff is available at:
> 
> http://people.freebsd.org/~brooks/patches/gif-stable.diff
> 
> apply with:
> 
> cd /usr/src
> mkdir sys/modules/if_gif sys/modules/if_stf
> patch < gif-stable.diff
> 
> -- Brooks

This works nicely on my -stale box.  Thanks.

One niggle though :)  It's probably worth changing 
``$FreeBSD: $'' to ``$FreeBSD$'' in your patched version.  
Without this, mergemaster assumes that the new version in /usr/src/etc 
is the same as the /etc version (same Ids).  This caused a problem 
here, I fixed the problem and went to prepare a patch for you the 
patch file came up empty -- you already had the missing ``create'' in 
your patches (of course) :*D

Cheers.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

kern/27767: (was: PPPoE + Alpha + 32/64 bits)

[Brian Somers]

Hi,

I think the attached will fix it properly -- but I haven't got an 
alpha to test with, so can someone do the honours for me ?

Ta.

> can you send us a patch that works for you?
> we can make it #ifdef __Alpha__  or something.
> 
> can you ocnfirm that the outgoing packet has a tag-lenth of '8'
> and that teh return tag has a length of '4'?
> (maybe 9 and 5)
> 
> sounds like a brain-dead router at the other end..
> 
> 
> On Wed, 1 Aug 2001, Thomas Pornin wrote:
> 
> > Hello,
> > 
> > I recently connected my FreeBSD/Alpha (4.3-RELEASE) to an ADSL link
> > using an Alcatel Speed Touch Home modem. As is, it was not working;
> > after some digging, I found that there is a bug either in the ng_pppoe
> > support, or in the modem.
> > 
> > The problem is in the pppoe_finduniq() function. In order to identify
> > sessions, the PPPoE code sends a tag with the first packet it sends to
> > the modem; this tag is in fact a 64-bit pointer to some data structure
> > in kernel space. When a packet of type PADO_CODE or PADS_CODE is
> > received, the tag is compared with known pointers.
> > 
> > However, only 32 bits are present in the return tag. So, if the original
> > pointer is 0xfc3b3d00, the tag contains only 0x003b3d00, which
> > are the first four bytes of data (in little-endian representation). If
> > I modify the pppoe_finduniq() function to accept matches on these four
> > bytes, the connection is established, and remains fully functionnal
> > afterwards.
> > 
> > Some details: The Alpha is little-endian, but the data in the packets is
> > big-endian. If the original pointer is 0xfc3b3d00, the rebuilt
> > tag from the response packet is actually 0x003b3d00. I do not
> > know if the 8-bytes tag is sent correctly, or if the modem is buggy, or
> > whatever.
> > 
> > Machine configuration:
> > AXPpci33 at 166 MHz, 32 MB ram
> > ethernet PCI adapter RealTek 8029 10baseT (ed0)
> > modem Alcatel Speed Touch Home (ethernet)
> > FreeBSD 4.3-RELEASE (with a small patch to enable ed0)
> > 
> > Feel free to ask for any detail.
> > 
> > 
> > --Thomas Pornin

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  

Index: ng_pppoe.c
===
RCS file: /home/ncvs/src/sys/netgraph/ng_pppoe.c,v
retrieving revision 1.45
diff -u -r1.45 ng_pppoe.c
--- ng_pppoe.c  2001/07/25 03:34:07 1.45
+++ ng_pppoe.c  2001/08/01 22:40:15
@@ -868,7 +868,7 @@
struct {
struct pppoe_tag hdr;
union   uniqdata;
-   } uniqtag;
+   } __attribute ((packed)) uniqtag;
 
/* 
 * kick the state machine into starting up
@@ -910,7 +910,7 @@
struct {
struct pppoe_tag hdr;
union   uniqdata;
-   } uniqtag;
+   } __attribute ((packed)) uniqtag;
negpneg = NULL;
struct mbuf *m;
 



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

Re: PPP help!

[Brian Somers]

> I have a problem with dialing into a server.
> I can dial in from a Windows system, so I know the account is working.
> PPP seems to be rejecting IPX/SPX
>   Aug  4 01:05:51 p3 ppp[398]: tun0: Phase: Unknown protocol 0x802b (Novell IPX 
>Control Protocol)

ppp(8) doesn't yet support IPX I'm afraid.  I may add support soon as 
I'm breaking all that code out for my ipv6 changes  Depends on 
how easy it looks :*)
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: taking ppp down and up

[Brian Somers]

Hi,

WRT killing ppp, the best way is:

  killall ppp; killall -2 ppp

The first tells ppp to exit cleanly and starts it trying to negotiate 
a shutdown with the other end.  The second kill tells ppp to just 
drop all existing connections.

WRT the PPPoE lockup problem, I'd love to get to the bottom of this 
(I can't reproduce it here).  If anybody can give me an account on a 
machine that locks up like this, I'd gladly have a crack at trying to 
solve the problem.

Cheers.

> We´re very happy with PPPoE into our cable modem
> 
> ´cept the whole link isn´t reliable :
> 
> ... for at least the reason that France Telecom (French-govt-protected 
> monopoly), God bless 'em, cripples their ADSL service by inserting 3 minute 
> blackouts, at the next hop at end their end of the ADSL, link throughout 
> the day, (ping to next hop dead) to protect their exorbitantly priced 
> leased-line service.
> 
> Usually after these blackouts, our FreeBSD PPPoE router just waits until 
> FT´s box responds again and all is.  We cast yet-another curse on FT, 
> re-start our ssh and pcAnywhere sessions, truck along.
> 
> The other pb is that sometimes, PPPoE doesn´t come back, and we wonder 
> whether maybe, in these cases, it´s really PPPoE halting, as I´ve seen 
> others report in these lists.  It´s the PPP from 4.3-Release .iso.
> 
> We of course need better reliability in the face of whatever PPP halts, so 
> we´re trying to come up with a script we could run to take down the link 
> (tun0, ppp) and then bring it up, and not having much success.   We also 
> run ipf and ipnat, so here´s what our script looks like:
> 
> ipf -D
> 
> killall ppp
> 
> kill `cat /var/run/ipmon.pid`
> 
> kill `cat /var/run/tun0.pid`
> 
> /usr/sbin/ppp -quiet -ddial -nat -unit0 meidsl
> 
> ipf -E
> ipf -Fa -f /etc/ipf-stats.rules
> ipnat -CF -f /etc/ipnat.rules
> /usr/sbin/ipmon -Dna /var/log/ipmon/iplog
> ~
> Running the above with the line up, we see this on the screen:
> 
> warning: /dev/tun0: Device busy
> 0 entries flushed from NAT table
> 0 entries flushed from NAT list
> Aug 20 12:51:13 gw0 /kernel: IP Filter: v3.4.19 unloaded
> gw0# Aug 20 12:51:13 gw0 /kernel: IP Filter: v3.4.19 unloaded
> Aug 20 12:51:13 gw0 /kernel: IP Filter: v3.4.19 initialized.  Default = 
> pass all, Logging = enabled
> Aug 20 12:51:13 gw0 /kernel: IP Filter: v3.4.19 initialized.  Default = 
> pass all, Logging = enabled
> Aug 20 12:51:13 gw0 ppp[1002]: Warning: /dev/tun0: Device busy
> 
> but the line doesn´t come up, until we run the same ppprest.sh script a 
> second time and get this on the screen:
> 
> No matching processes were found
> cat: /var/run/tun0.pid: No such file or directory
> cat: /var/run/tun0.pid: No such file or directory
> usage: kill [-s signal_name] pid ...
> kill -l [exit_status]
> kill -signal_name pid ...
> kill -signal_number pid ...
> Aug 20 12:52:23 gw0 /kernel: IP Filter: v3.4.19 unloaded
> Aug 20 12:52:23 gw0 /kernel: IP Filter: v3.4.19 unloaded
> 0 entries flushed from NAT table
> 0 entries flushed from NAT list
> gw0# Aug 20 12:52:23 gw0 /kernel: IP Filter: v3.4.19 initialized.  Default 
> = pass all, Logging = enabled
> Aug 20 12:52:23 gw0 /kernel: IP Filter: v3.4.19 initialized.  Default = 
> pass all, Logging = enabled
> 
> and the PPP link comes up again.
> 
> We´ve tried a lot of different sequences for the script, but nothing works 
> ON THE FIRST SCRIPT RUN, so we think we´re got wrong or missing commands.
> 
> Any suggestions?
> 
> Also, anybody have any ideas for a probe that will distinguish between when 
> the FT blackout is the pb (ie, don´t run PPP restart script) vs when PPPoE 
> is hung?
> 
> Len
> 
> 
> http://MenAndMice.com/DNS-training
> http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K
> http://IMGate.MEIway.com  : Build free, hi-perf, anti-abuse mail gateways

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: taking ppp down and up

[Brian Somers]

> >WRT the PPPoE lockup problem, I'd love to get to the bottom of this
> >(I can't reproduce it here).  If anybody can give me an account on a
> >machine that locks up like this, I'd gladly have a crack at trying to
> >solve the problem.
> 
> we are not sure we have the ppp lockup, but we certainly have the "FT lockout".
> 
> We are willing to give you an ssh account, but when we´re down .  :))
> 
> Do you have any ideas WRT, from POV of the PPP machine, how to distinguish 
> between local ppp lockup vs ppp ok but remote nexthop dead?

I think monitoring the network for PPPoE traffic should say whether 
or not the local end is dead (no traffic == local death).  ``tcpdump 
-i iface -l not ip'' should do it.

Assuming there's no traffic, it may be necessary to install a modified 
netgraph module - one that logs when it's setting up and triggering 
timeouts.  I did this some time ago here, but could never get 
anything to lock up :(  I've been told that ``killall -11 ppp'' or 
attaching to ppp with gdb just shows ppp in select() (as expected), 
but it may be worth confirming this too.

I can only guess that the problem is due to netgraph mis-processing 
some rogue data from the other side (data I can't reproduce here 'cos 
I'm using netgraph).  To this end, it may even be worth running 
tcpdump permanently on the link (with -x) so that we can get a look 
at the dodgy data.

> Len
> 
> 
> http://MenAndMice.com/DNS-training
> http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K
> http://IMGate.MEIway.com  : Build free, hi-perf, anti-abuse mail gateways

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: taking ppp down and up

[Brian Somers]

> 
> >>There is no 3 minute blackout. The session is just closed. Change
> >>lqrperiod if you want a shorter deconnexion.
> >
> >Merci bcp, so that´s where from the repeatable 6 x 30 seconds comes!! thanks

Of course your provider should be sending a PADT...  perhaps their 
end is crashing or something ?

> but
> with ppp.conf having:
> 
>   enable lqr
>   set lqr accept
>   set lqrperiod 3
> 
> we get:
> 
> Aug 20 15:51:11 gw0 ppp[1672]: Warning: 0: Invalid lqr period - min 2
> Aug 20 15:51:11 gw0 ppp[1672]: Warning: set lqr: Failed 1
> 
> what is the syntax for "set lqrperiod" ?   man ppp is clear but our syntax 
> is not accepted.

The middle line is the problem -- atoi("accept") == 0.

> Len
> 
> 
> http://MenAndMice.com/DNS-training
> http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K
> http://IMGate.MEIway.com  : Build free, hi-perf, anti-abuse mail gateways

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: PPPoE dying too long

[Brian Somers]

> > >  set device PPPoE:ste0:meidsl
> > >  set speed sync
> > >  set mru 1454
> > >  set mtu 1454
> >
> >Why 1454 ? 1492 is normally what you want.
> 
> ok, we´ll look at that.

This is now imposed by ppp, so you *should* be able to remove the 
``set mru'' and ``set mtu'' lines in 4.4-release and -current.

> thanks
> Len
> 
> 
> http://MenAndMice.com/DNS-training
> http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K
> http://IMGate.MEIway.com  : Build free, hi-perf, anti-abuse mail gateways

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: PPP not adding an interface route

[Brian Somers]

> Hi All
> 
> 
> I am running FreeBSD 4.4-RC, compiled on the 7-september and have found
> that PPP is not adding a local interface route when the link comes up.  I
> am using a legal subnet as follows:
> 
> 
> tun0: flags=8051 mtu 1500
> inet6 fe80::260:97ff:fe7b:3dc2%tun0 prefixlen 64 scopeid 0xa 
> inet 192.168.252.2 --> 192.168.252.1 netmask 0xfffc 
> Opened by PID 117
> 
> but the route table shows:
> 
> bash-2.04# netstat -arn
> Routing tables
> 
> Internet:
> DestinationGatewayFlagsRefs  Use  Netif Expire
> 127.0.0.1  127.0.0.1  UH  2  180lo0
> 192.168.6  link#1 UC  10xl0
> 192.168.6.255  ff:ff:ff:ff:ff:ff  UHLWb   11xl0
> 192.168.252.1  192.168.252.2  UH  2   59   tun0

ppp has never automatically added a lo0 route.  If ppp detects an 
outbound packet destined for the local interface address and 
``loopback'' is ``enabled'' (the default), it'll turn the packet 
around, but that's the extent of it's helpfulness.

> Thanks
> 
> David Hunt

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Forward: Re: ping gif0

[Brian Somers]

> I'm forwarding a message directly to me, with a permission of the
> sender, because I myself do not have enough time to tackle this.
> 
>   JINMEI, Tatuya
>   Communication Platform Lab.
>   Corporate R&D Center, Toshiba Corp.
>   [EMAIL PROTECTED]
[.]
> > > 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.
[.]

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.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Forward: Re: ping gif0

[Brian Somers]

> >>>>> 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.

I had two LANs with an IP4 gif tunnel between them and an IPSEC 
transport policy encrypting ip4 data between the two public IP 
addresses.  From anywhere on LAN1 I could send & receive data to 
the LAN2 private gateway IP number, but could not send data to any 
internal machines on LAN2.  Trying to talk to internal machines on 
LAN2 resulted in authentication errors for the data coming into LAN1s 
gateway.

Upgrading racoon on LAN2's gateway made the problem go away

>   JINMEI, Tatuya
>   Communication Platform Lab.
>   Corporate R&D Center, Toshiba Corp.
>   [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Forward: Re: ping gif0

[Brian Somers]

> 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.

> --
> Matt Emmerton

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Forward: Re: ping gif0

[Brian Somers]

> 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?

I think so.  Try changing it to
spdadd 209.167.75.124/32 209.167.75.123/32 ip4 -P in ipsec esp/transport//require;
spdadd 209.167.75.123/32 209.167.75.124/32 ip4 -P out ipsec esp/transport//require;

> --
> Matt Emmerton

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: simple static NAT question

[Brian Somers]

> If you have multiple private ip's pointing to the same public ip will
> traffic originating from each individual ip going out find it's way back to
> the original internal ip on its way back in?

Yes.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: IPSEC question..

[Brian Somers]

> The sample docs and the daemon-news
> article get me part way started to making an encrypted
> tunnel using IPsec4 between two networks.
> However The are really quite confusing...
> 
> Is there a SIMPLE description of what all the parts do?
> 
> I have a gif tunnel going, but it's not clear to me how I make this tunnel 
> start encrypting the damned data.
> 
> I've fiddled with several commands (e.g. setkey) but tcpdump keeps showing 
> plain encapsulated packets...no encryption..

Once you've got the gif tunnel working, say with top addresses 
10.0.0.1 and 10.0.0.2 and tunnel addresses 1.2.3.4 and 5.6.7.8, 
create an /etc/ipsec.conf that says:

  spdadd 1.2.3.4/32 5.6.7.8/32 ip4 -P in ipsec esp/transport//require;
  spdadd 5.6.7.8/32 1.2.3.4/32 ip4 -P out ipsec esp/transport//require;

This is your setkey input.  The ``ip4'' bit tells ipsec to only touch 
IP-in-IP traffic, so comms going from an internal LAN to an external 
gateway address (1.2.3.4 or 5.6.7.8) won't be encrypted (but may be 
NAT'd).  Only the gif-encapsulated traffic is encrypted.

Then add this to /etc/rc.conf:

  ipsec_enable=YES
  ipsec_file=/etc/ipsec.conf

Once this is done, arrange to have racoon running on each end and 
everything should work.  Using a shared secret in /usr/local/etc/
racoon/psk.txt is the easiest:

1.2.3.4 akeythatnobodyisgoingtocrack

and running racoon -F helps initially.

> -- 
> ++   __ _  __
> |   __--_|\  Julian Elischer |   \ U \/ / hard at work in 
> |  /   \ [EMAIL PROTECTED] +-->x   USA\ a very strange
> | (   OZ)\___   ___ | country !
> +- X_.---._/presently in San Francisco   \_/   \\
>   v

Good luck !
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: ipfilter and IPSec processing order

[Brian Somers]

Hi,

I can't answer your question specifically as I've never used 
ipfilter, but it's certainly possible to use natd at the same time as 
IPSEC... the vital thing is to ensure that no traffic is altered by 
both engines.

Using a gif tunnel (which you are already) and encrypting only ipencap 
traffic in your spdadd/transport policy should mean that the nat 
engine either sees regular traffic (that should be NATd) or ipencap 
traffic (which shouldn't be NATd, and won't as the src address is the 
gateway address).

So the bit you may be missing is the ``ip4'' bit in the setkey spdadd 
line

> Hi,
> 
> I use an IPSec tunnel (transport mode + gif) between two FreeBSD 4.3-p19
> gateways, using ipfilter(v3.4.20 (264)) as packet filter.
> 
> With no particular statement about IPSec, I get this message:
> 
> Sep 21 10:10:24 fw ipmon[94]: 10:10:23.578447 fxp0 @0:80 b 213.41.X.Y ->
> 213.41.W.Z PR ipencap len 20 (104) OUT 
> when I try to make my packets go out.
> 
> Fine. I let protocol IP ENCAP (4) go through the firewall.
> 
> Then, I get: Sep 21 10:13:40 fw ipmon[94]: 10:13:39.593013 fxp0 @0:90 b
> 213.41.W.Z -> 213.41.X.Y PR esp len 20 (136) IN 
> when packets come back to the gateway.
> 
> Fine. I let protocol ESP(50) go through the firewall.
> 
> I can now ping the both ends of the tunnel. Because I explicitely allowed ICMP
> to go through ipf rules. Unfortunately, when I try to telnet the other side of
> the tunnel, on HTTP's port, using the private network adresses:
> 
> Sep 21 10:15:43 fw ipmon[94]: 10:15:42.698858 fxp0 @0:91 b 192.168.202.17,80 ->
> 192.168.1.1,1259 PR tcp len 20 44 -AS IN 
> 
> responses are not allowed to come back.
> 
> I even tried to put stateful rules for the private networks:
> 
> pass out quick proto tcp from 192.168.0.0/17  to 192.168.128.0/17  keep state
> 
> Unsuccessfully.
> 
> So I am wondering, why is ipfilter seeing the packet twice: once encapsulated,
> once decaspulated ?
> 
> I looked at freebsd-net, -security, and ipfilter mailing lists, with no success.
> 
> NetBSD states that:
>  « Since February 2001, on NetBSD-current, ipf(4)/IPsec interaction was
> clarified as below: 
>  ipf(4) looks at packets in native wire format only. ipf(4) looks at
> packets before IPsec processing on inbound, and after IPsec processing on
> outbound. »
> 
> Is it done on FreeBSD ? Why can't it be done ( I read threads where people
> stated that packet filter and IPSec interaction was an unsolvable problem).
> 
> And even if the packet goes twice through the packet filter, why can't I use
> stateful rules ? Hum !?
> 
> Cheers,
> 
> -- 
> Sameh

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: IPSEC question..

[Brian Somers]

> Le (On) Fri, Sep 21, 2001 at 09:47:03AM +0100, Brian Somers ecrivit (wrote):
> > 
> >   spdadd 1.2.3.4/32 5.6.7.8/32 ip4 -P in ipsec esp/transport//require;
> >   spdadd 5.6.7.8/32 1.2.3.4/32 ip4 -P out ipsec esp/transport//require;
> > 
> > This is your setkey input.  The ``ip4'' bit tells ipsec to only touch 
> > IP-in-IP traffic, so comms going from an internal LAN to an external 
> > gateway address (1.2.3.4 or 5.6.7.8) won't be encrypted (but may be 
> > NAT'd).  Only the gif-encapsulated traffic is encrypted.
> 
> Hum, looks great, but the man page for setkey says:
> 
> « spdadd src_range dst_range upperspec policy ;
> 
>  upperspec
>  Upper-layer protocol to be used.  Currently tcp, udp and any can
>  be specified.  any stands for ``any protocol''. »
> 
> And when I use 'ip4' instead of any/icmp/tcp/udp, it says: 
> line #[where ip4]: Syntax error at [i].
> 
> (Funny error location, by the way).
> 
> Is it a « new feature » with 4.4's shipped KAME's setkey ?

Yes, it was added by me specifically to permit NAT & IPSEC to work 
together (although the KAME guys have made it better by now allowing 
any protocols(5) value.

The patch is very simple, so you may want to patch your system 
(kernel support is already there, it's just a one-line userland 
change).

> -- 
> Sameh

Cheers.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  

Index: token.l
===
RCS file: /home/ncvs/src/usr.sbin/setkey/token.l,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- token.l 4 Jul 2000 16:22:05 -   1.3
+++ token.l 17 May 2001 15:30:49 -  1.4
@@ -200,6 +200,7 @@
/* upper layer protocols */
 icmp   { PREPROC; yylval.num = IPPROTO_ICMP; return(UP_PROTO); }
 icmp6  { PREPROC; yylval.num = IPPROTO_ICMPV6; return(UP_PROTO); }
+ip4{ PREPROC; yylval.num = IPPROTO_IPV4; return(UP_PROTO); }
 tcp{ PREPROC; yylval.num = IPPROTO_TCP; return(UP_PROTO); }
 udp{ PREPROC; yylval.num = IPPROTO_UDP; return(UP_PROTO); }
 



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

Re: IPSEC question..

[Brian Somers]

> > Once you've got the gif tunnel working, say with top addresses 
> > 10.0.0.1 and 10.0.0.2 and tunnel addresses 1.2.3.4 and 5.6.7.8, 
> > create an /etc/ipsec.conf that says:
> 
> 
> which are the 'top' addresses? outer or inner?
> i.e. 
> 
>(A)gif0:---(B)ed0-ed0(C)gif0(D)

By ``top'' I mean the gif addresses.  By tunnel addresses I mean the 
endpoint addresses.  For my examples:

gif0: flags=8051 mtu 1280
tunnel inet 1.2.3.4 --> 5.6.7.8
inet 10.0.0.1 --> 10.0.0.2 netmask 0x 

> >   spdadd 1.2.3.4/32 5.6.7.8/32 ip4 -P in ipsec esp/transport//require;
> >   spdadd 5.6.7.8/32 1.2.3.4/32 ip4 -P out ipsec esp/transport//require;
> > 
> 
> ip4?
>  I need to run this on 4.1.1 machines.

You're really better off applying the one-line fix to token.l to 
support the ip4 syntax.  It removes many problems - especially if you 
intend to run NAT on your machines.

You should have the kernel support in 4.1.1.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: VPN client with mpd

[Brian Somers]

> Hi,
> 
> I'm trying to set up a VPN client on my FreeBSD laptop, so I can tunnel
> through to work from home. I've played with both mpd and pptpclient from
> ports, and mpd seems more robust (pptpclient likes to sometimes start
> eating all CPU time). So I'd decided to to this with mpd; please let me
> know if this was the wrong choice from the start.
> 
> Here's my setup:
> 
> LAPTOP <-> NAT <--...INTERNET...--> VPN-SERVER <-> INTRANET
> 
> I started with the examples under /usr/local/etc/mpd, slightly changing
> the defaults to what I thought were the correct values for my setup.
> I've created mpd.secret with the correct login/password mapping for
> LOGIN.
> 
> Here's my mpd.conf:
> 
>   default:
>   load vpn
>   
>   vpn:
>   new -i ng1 vpn vpn
>   set iface disable on-demand
>   set iface addrs 192.168.1.1 192.168.2.1
>   set iface idle 0
>   set iface route 192.168.2.0/24
>   set bundle disable multilink
>   set bundle authname 
>   set link yes acfcomp protocomp
>   set link no pap
>   set link yes chap
^
I'm no mpd expert, but I believe this makes mpd insist that the peer 
authenticates itself.

Try removing it.

[.]
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Diagnostics question with PPPoE

[Brian Somers]

> 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?

I think something should have come up just before the quoted log 
entry.  Maybe you need to enable more logging ?

Maybe ``set log phase lcp ipcp command chat tun ccp'' ?  If nothing 
still shows up, adding ``debug'' to the above list should help 
(although it'll make for somewhat more verbose logs...).

> --
> Matt Emmerton

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: IPv6 over (IPv4 over user-PPP over ISDN) using FreeBSD

[Brian Somers]

Try using the -current version of ppp.  It supports IPv6 natively.

You need to use ``iface add'' to assign non-link-level addresses.  
For example, I've got this in my laptop's config:

 iface add 2001:6f8:602:1::12   # global
 iface add fec0::1:12 fec0::1:1 # site-local

> Hi,
> 
> I've been testing IPv6 over IPv4 over User-PPP over ISDN on Freebsd 4.3-stable. 
> 
> I've managed to establish the PPP/ISDN connection between a machine acting as a 
>server and the other as a client (using Xyzel TA). Both the machine can ping to one 
>another.
> 
> But the problem arises when I try to establish a tunnel(ipv6 o ipv4) using gif via 
>the PPP/ISDN connection which uses tun interface.
> 
> Here's what I did:
> 
> Assuming the server has 10.0.0.1 and client has 10.0.0.2 address on their tun 
>interfaces.
> 
> ##server side##
> 
> ifconfig gif0 up 
> ifconfig gif0 IPv6src-add IPv6dst-add
> gifconfig gif0 10.0.0.1 10.0.0.2
> 
> ##client side##
> 
> ifconfig gif0 up
> ifconfig gif0 Ipv6src-add IPv6dst-add
> gifconfig gif0 10.0.0.2 10.0.0.1
> 
> At this stage, I should be able to ping6 -I gif0 ff02::1 to verify that the gif 
>tunnel is establish. However, it didn't on tun interface.
> 
> As far as I know, it worked when i tried tunnelling on physical interfaces like xl0 
>or xl1 with valid IPv4 addresses.
> 
> 
> Anyone got any ideas?
> 
> btw, anyone knows about or tried PPPv6 ??
> 
> 
> thanks in advance,
> 
> Kim Chua
> Multimedia Super Corridor (MSC)
> Cyberjaya
> Malaysia

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: PPP problem

[Brian Somers]

You could try enabling tcp/ip and physical logging to see if data is 
being written as expected.

I'd be surprised if this was a ppp problem - it doesn't look at the 
frame payload unless you're using NAT, filtering, or some of the more 
nasty log levels.  Perhaps you've got some rogue firewall rules ?

> I am unable to bring up PPP to my ISP. DNS works, but PING and all TCP-based
> protocols don't. I haven't tried any other UDP-based protocols. I have copied
> here ifconfig -a and netstat -rn output both before bringing the link up and
> while it is up. Lastly I have also copied the relevant lines from ppp.log.
> 
> Does anybody have any idea what is going wrong and how I can fix it?
> 
> Alex Thorp
> 
> # cat /etc/ppp/ppp.conf
> 
> default:
> set log local phase lcp ipcp debug
> set device /dev/cuaa1
> set speed 115200
> set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK
> \\dATDT\\T TIMEOUT 40 CONNECT"
> 
> freeserve:
> set phone "0123456789"
> set login
> set authname MYUSERNAME
> set authkey MYPASSWORD
> set timeout 180
> set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
> add default HISADDR
> enable dns
> 
> # uname -a
> FreeBSD MYMACHINE.MYDOMAIN.CO.UK 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Tue Sep 18
> 11:57:08 PDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC 
> i386
> 
> # ifconfig -a
> ep0: flags=8843 mtu 1500
> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
> inet6 fe80::260:97ff:fe16:71bf%ep0 prefixlen 64 scopeid 0x1 
> ether 00:60:97:16:71:bf 
> media: Ethernet 10baseT/UTP
> 
> lp0: flags=8810 mtu 1500
> lo0: flags=8049 mtu 16384
> inet6 ::1 prefixlen 128 
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
> inet 127.0.0.1 netmask 0xff00 
> ppp0: flags=8010 mtu 1500
> sl0: flags=c010 mtu 552
> faith0: flags=8000 mtu 1500
> 
> # netstat -rn
> Routing tables
> 
> Internet:
> DestinationGatewayFlagsRefs  Use  Netif Expire
> 127.0.0.1  127.0.0.1  UH  00lo0
> 192.168.1  link#1 UC  10ep0
> 192.168.1.50:60:8c:b9:82:ac   UHLW2  679ep0830
> 
> Internet6:
> Destination   Gateway   Flags  Netif
> Expire
> ::1   ::1   UH  lo0
> fe80::%ep0/64 link#1UC  ep0
> fe80::260:97ff:fe16:71bf%ep0  0:60:97:16:71:bf  UHL lo0
> fe80::%lo0/64 fe80::1%lo0   Uc  lo0
> fe80::1%lo0   link#3UHL lo0
> ff01::/32 ::1   U   lo0
> ff02::%ep0/32 link#1UC  ep0
> ff02::%lo0/32 ::1   UC  lo0
> 
> # ppp -background freeserve
> Working in background mode
> Using interface: tun0
> Debug: ReadSystem: Checking freeserve (/etc/ppp/ppp.conf).
> Debug: wrote -1: cmd = Add, dst = 0, gateway = 20a
> PPP enabled
> Phase: Parent: PPP enabled
> 
> # ping www.freebsd.org
> PING freefall.freebsd.org (216.136.204.21): 56 data bytes
> ^C
> --- freefall.freebsd.org ping statistics ---
> 16 packets transmitted, 0 packets received, 100% packet loss
> 
> # netstat -rn
> Routing tables
> 
> Internet:
> DestinationGatewayFlagsRefs  Use  Netif Expire
> default195.92.66.8UGSc1   26   tun0
> 127.0.0.1  127.0.0.1  UH  00lo0
> 192.168.1  link#1 UC  10ep0
> 192.168.1.50:60:8c:b9:82:ac   UHLW2 1578ep0643
> 195.92.66.862.136.215.63  UH  20   tun0
> 
> Internet6:
> Destination   Gateway   Flags  Netif
> Expire
> ::1   ::1   UH  lo0
> fe80::%ep0/64 link#1UC  ep0
> fe80::260:97ff:fe16:71bf%ep0  0:60:97:16:71:bf  UHL lo0
> fe80::%lo0/64 fe80::1%lo0   Uc  lo0
> fe80::1%lo0   link#3UHL lo0
> fe80::%tun0/64fe80::260:97ff:fe16:71bf%tun0 Uc tun0
> fe80::260:97ff:fe16:71bf%tun0 link#7UHL lo0
> ff01::/32 ::1   U   lo0
> ff02::%ep0/32 link#1UC  ep0
> ff02::%lo0/32 ::1   UC  lo0
> ff02::%tun0/32fe80::260:97ff:fe16:71bf%tun

Re: IPv6 /PPP using FreeBSD 4.4

[Brian Somers]

>  Hi Brian,
> 
> thanks for your help..i got the Ipv6 ppp working now with the latest version of ppp 
>from your site
> 
> But i encountered another problem, on freebsd 4.4-stable, you cannot
> use ifconfig to point to a destination address like below
> 
> ifconfig tun0 inet6 3ffe:1800:100:1::1 prefixlen 48 3ffe:1800:100:1::2 prefixlen 48
> 
> do you know why?

Bearing in mind that when assigning a destination address, you must 
use a prefixlens of 128, you need to do this in ppp:

  iface add 3ffe:1800:100:1::1  3ffe:1800:100:1::2
  add 3ffe:1800:100:1::2/48  3ffe:1800:100:1::1

> Another question...
> 
> is there anyway of controlling ipv6 address and routes in ppp.conf when using auto 
>mode demand dialing...??
> 
> thanks,

Sure - with ``iface add'' to assign interface addresses and ``add'' 
to add routes - that's what I was hinting at in my original mail.

> Kim chua
> 
> 
> 
> 
> 
> 
> --
> 
> On Thu, 18 Oct 2001 10:29:28  
>  Brian Somers wrote:
> >Try using the -current version of ppp.  It supports IPv6 natively.
> >
> >You need to use ``iface add'' to assign non-link-level addresses.  
> >For example, I've got this in my laptop's config:
> >
> > iface add 2001:6f8:602:1::12   # global
> > iface add fec0::1:12 fec0::1:1 # site-local
> >
> >> Hi,
> >> 
> >> I've been testing IPv6 over IPv4 over User-PPP over ISDN on Freebsd 4.3-stable. 
> >> 
> >> I've managed to establish the PPP/ISDN connection between a machine acting as a 
>server and the other as a client (using Xyzel TA). Both the machine can ping to one 
>another.
> >> 
> >> But the problem arises when I try to establish a tunnel(ipv6 o ipv4) using gif 
>via the PPP/ISDN connection which uses tun interface.
> >> 
> >> Here's what I did:
> >> 
> >> Assuming the server has 10.0.0.1 and client has 10.0.0.2 address on their tun 
>interfaces.
> >> 
> >> ##server side##
> >> 
> >> ifconfig gif0 up 
> >> ifconfig gif0 IPv6src-add IPv6dst-add
> >> gifconfig gif0 10.0.0.1 10.0.0.2
> >> 
> >> ##client side##
> >> 
> >> ifconfig gif0 up
> >> ifconfig gif0 Ipv6src-add IPv6dst-add
> >> gifconfig gif0 10.0.0.2 10.0.0.1
> >> 
> >> At this stage, I should be able to ping6 -I gif0 ff02::1 to verify that the gif 
>tunnel is establish. However, it didn't on tun interface.
> >> 
> >> As far as I know, it worked when i tried tunnelling on physical interfaces like 
>xl0 or xl1 with valid IPv4 addresses.
> >> 
> >> 
> >> Anyone got any ideas?
> >> 
> >> btw, anyone knows about or tried PPPv6 ??
> >> 
> >> 
> >> thanks in advance,
> >> 
> >> Kim Chua
> >> Multimedia Super Corridor (MSC)
> >> Cyberjaya
> >> Malaysia

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: IPv6 /PPP using FreeBSD 4.4

[Brian Somers]

>  Hi Brian,
> 
> thanks alot for your info.. I can assigned IPv6 address using ppp.conf like you 
>showed me. 
> 
> However, when ppp was started using ppp -auto, tun0 appears and 
> you can see the assigned IPv6 address on tun0. But when the connection 
> is established with the peer, tun1 appears and tun1 is where the 
>  actual connection established with the link local addresses.
> 
> What i want to achieve is to have the connection established at 
> tun0 where the global IPv6 was already assigned...

This is what should be happening.

I would guess that something else on your machine is starting another 
ppp invocation (on tun1) - although this sounds bizarre.

> Below is the ifconfig from my machine:
> 
> 
> tun0: flags=8051 mtu 1500
> inet6 fe80::250:4ff:fec1:ba68%tun0 prefixlen 64 scopeid 0x8
> inet 10.0.0.2 --> 10.0.0.1 netmask 0xff00
> inet6 2001:200:703:1::1 --> 2001:200:703:1::2 prefixlen 128
> Opened by PID 2025
> tun1: flags=8051 mtu 1500
> inet6 fe80::250:4ff:fec1:ba68%tun1 prefixlen 64 scopeid 0x9
> inet 0.0.0.0 --> 192.168.100.2 netmask 0xff00
> inet6 fe80::86e4:81d4%tun1 --> fe80::3a48:d102%tun1 prefixlen 128 scopei
> d 0x9
> Opened by PID 2007
> tun2: flags=8010 mtu 1500
> inet6 fe80::250:4ff:fec1:ba68%tun2 prefixlen 64 scopeid 0xa
> 
> 
> any ideas how to prevent the above from occuring???

I guess that depends on what's starting the second ppp invocation.

> thanks in advance,
> 
> kim chua
> --
[.]
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: ng_pppoe accounting?

[Brian Somers]

I've just implemented a ``log'' command in ppp.

You can now do something like ``log ${MACADDR} HISADDR USER UPTIME'' 
to your ppp.linkdown.

The only missing bit is getting pppoed to put $MACADDR into ppp's 
environment

> Julian Elischer wrote:
> 
> > On Tue, 30 Oct 2001, QUEVEDO BUSTILLOS Jose Federico wrote:
> >
> > > Hi,
> > >
> > > I'm a newbie in netgraph structures and I will like to ask your advice
> > > about some PPPoE related ideas.
> > >
> > > I'm using a FreeBDS box with PPPoE installed and working as a gateway.  My
> > > goal is to establish basic administration and accounting for PPPoE users.
> > >
> >
> > You are using pppoed to offer pppoe service?
> 
> I'm thinking of using pppoed as a server that offers connection to internal
> network boxes (essentially laptops) that want to establish an Internet connexion
> acces.
> 
> 
> Lab
> University Network
> 
> ---¦
> ¦-
> internal network   ¦ --- FreeBSD box ---¦   Internet
> 
> pppoe clients  --¦
> (pppoed)   ¦
> 
> 
> 
> > > The basic accounting needs (not with commercial goals) are:
> >
> > As a server or as a client?
> >
> > >
> > > 1. Keep track of the MAC addresses and users names of the PPPoE
> > > connections to the gateway, store time connection of the session and
> > > traffic generated.
> >
> > Is this the kind of logging you want?
> > (I don't have this.. I did it by hand)
> >
> > 13:23:20 2001-10-29   00:23:33:01:23:54 julian 192.168.1.1
> > 13:24:30 2001-10-29   00:01:43:11:45:78 bob 192.168.1.3
> > 13:25:11 2001-10-29   00:23:33:76:2:24 paul 192.168.1.5
> > 13:35:10 2001-10-29   00:23:33:01:23:54 *close* 12334354 in 32412344 out
> > ...
> 
> Is exactly what I would like to generate!
> 
> > The ppp daemon could do this if it knew the associated link and could
> > retrieve the MAC address associated with it.
> >
> > there are several roadblocks..
> > 1/the ppp daemon doesn't keep a control socket associated with the
> > connection so it can't inquire about the MAC address.
> 
> I was thinking to give pppoed (during the discovery phase) the possibility to
> select the IP from a pool of IP address (the same as ppp does -  FreeBSD pppd
> does?), match it with MAC address of client that is well  known at this stage
> and generate this part of our supposed loggin file:
> 
> Time_of_starting_connection  MAC_address   IP_address
> 13:23:2000:23:33:01:23:54192.168.1.1
> 
> 13:24:3000:01:43:11:45:78192.168.1.3
> 
> Then, the call message to ppp could be:
> 
> exec /usr/sbin/ppp -direct -set ifaddr "localhost_ip" "IP_assigned_by_pppoed"
> 
> and the log file already generated could be used by ppp to retrive MAC
> address.???
> 
> > 2/ If it were to try create a new control socket, it could not connect it
> > to the existing data socket.
> >
> > It may be possible that the ppp daemon might know the netgraph node name
> > for the data socket node, in which case it could get the information
> > requested.
> > This would require an answer from Brian
> >
> > > 2. Dynamic assignation of IP address. (I think on two possibilities a)
> > > PPPoE assignation: when PADR arrives, the gw should look into a pool of IP
> > > adresses and assign one "before calling PPP". B) leave PPP the assignation
> > > and capture the IP in other way).
> >
> > I think you need to leave it to ppp.
> > but maybe ppp can become aware of teh MAc address.
> >
> > >
> > > Result: A log file produced with a session match of:
> > >
> > > MAC add - IP add - username - time of session.
> > >
> > > Should I touch the ng_pppoe code? or should I create a netgraph node to
> > > place between ng_node and ng_ppp?
> > > Am I on the good way
> >
> > Probably not good to touch the pppoe code..
> > until you discuss it with Brian.
> > Then when you can agree on what needs to be changed we can change it.
> > the ppp code needs to be in charge..
> 
> Thanks,
> 
> Federico
> 
> >
> > >
> > > Thanks in advance,
> > >
> > > Federico Quevedo
> > >
> > > .
> > > Federico Quevedo
[.]
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

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

[Brian Somers]

> 
> 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.

I dynamically load all the modules required for client and server 
PPPoE on -stable and -current without problems:

$ kldstat
Id Refs AddressSize Name
 18 0xc010 3434b8   kernel
 21 0xc1408000 c3000vinum.ko
 31 0xc14f4000 5000 ip6fw.ko
 44 0xc161d000 9000 netgraph.ko
 51 0xc162a000 3000 ng_socket.ko
 61 0xc162d000 3000 ng_ether.ko
 71 0xc1632000 5000 ng_pppoe.ko
 81 0xc164e000 4000 if_tun.ko

There is a problem where many of the NIC drivers get confused when 
netgraph gives them packets before they're IFF_UP'd.  ppp now works 
around the problem by bringing the interface up as required.

The originator should try building the latest version of ppp on his 
4.2 machine and see if that helps.

> -- 
> 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.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Strange problem with PPP/Netgraph (PPPoE)

[Brian Somers]

> 
> > What is happening is that when ppp starts on bootup (ppp -quiet -ddial
> > pppoe), the last entry is "dial -> carrier" and nothing else.  Normally
> 
> Looks like that the ethernet connection between your host and the modem is
> broken. I get the same message when I unplug my ethernet wire.

Sounds plausible.  I guess a tcpdump would tell

> Cheers
> Martin

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: cvs commit: src/sys/netinet in.c

[Brian Somers]

> brian   2001/11/30 06:00:55 PST
> 
>   Modified files:
> sys/netinet  in.c 
>   Log:
>   During SIOCAIFADDR, if in_ifinit() fails and we've already added an
>   interface address, blow the address away again before returning the
>   error.
>   
>   In in_ifinit(), if we get an error from rtinit() and we've also got
>   a destination address, return the error rather than masking EEXISTS.
>   Failing to create a host route when configuring an interface should
>   be treated as an error.
>   
>   Revision  ChangesPath
>   1.61  +39 -24src/sys/netinet/in.c

It's possible that EEXIST being returned from in_ifinit() should not 
be masked at all, except for the ``netmask == 0x'' case so that 
we can't have conflicting interface addresses

I'm not sure about this though, so I've cc'd  freebsd-net.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Brian: pppoe question.

[Brian Somers]

> Brian, would it be possible to specify to ppp, an arbitrary node/hook on
> which to attach the pppoe node?

Just to see if I understand, do you mean to connect to ``something 
else'' besides [NIC]:orphan ? - so that another node can be put in 
the chain ?

The netgraph code on the cvs NETGRAPH branch should be able to do 
this although I haven't tested it for some time.  The idea is that 
you can configure a chain of nodes, sending them ascii messages if 
required.  The nodes are arbitrary...
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: PPP callback and SecurID

[Brian Somers]

You could probably ``set cd off'' to get the desired effect.  
Alternatively, configure your machine to be able to receive incoming 
connections and let the initial ppp session drop when the peer hangs 
up.

> I've a problem with my callback. I'd like to automate it somehow, but there is a
> problem with LCP.
> 
> The hard way is to do something like:
> 
> # ppp ras
> ppp ON pf39> term
> deflink: Entering terminal mode on /dev/cuaa1
> Type `~?' for help
> atdt
> CONNECT 57600
> 
> 
> User Access Verification
> 
> Username: 
> Enter PASSCODE: 
> 
> Callback initiated - line is disconnected
> 
> NO CARRIER
> 
> RING
> 
> RING
> 
> ATA
> .. (the connection)
> 
> I tried to do something like this:
> 
> [ppp.conf]
> ...
> callback:
>   disable pap
>   disable chap
>   set speed 57600
>   set phone 
>   set cd off
>   set device /dev/cuaa1
>   allow users *
> set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 10 \"\" ATZ OK ATDT\\T 
>TIMEOUT 40 CONNECT"
> set login "TIMEOUT 15 sername: szak PASSCODE: 
>\"!/usr/X11R6/bin/ssh-askpass\" Callback ATA"
> 
> But it bails out, because the connection is apparently considered open by ppp
> after the disconnection, so I can't make the modem accept connections with ATA
> command in this state.
> 
> Does anyone have other ideas how to make it work without typing the sequence
> everytime with term?
> 
> Thanks, /S

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: pptp + mschap

[Brian Somers]

Hi,

I don't know a great deal about PPTP, but as it happens, I recently 
looked for a radius server that'd talk MSCHAPv2 - so that I could teach 
ppp to do it.

I couldn't find any support in the ports, and then our [potential] 
client backed out, so I never got any further.

If you could find a spec on how to talk MSCHAP & MSCHAPv2 to a radius 
server, I'd certainly be happy to add support to ppp.  You never know 
- the client may come back :*)

Cheers.

> my company recently switched from a nortel vpn system to a radius based 
> scheme that is very windows-centric.  i had no problems connecting to the 
> nortel using pptpclient (from the ports).
> 
> now it seems i'm being thrown by ms-chap authentication.  i don't really 
> know how to set this up.  as far as i can see from reading the 
> documentation that comes with pptpclient, this should suffice:
> 
> cnet:
>   set authname cnet\\jdrukman
>   set authkey x
>   set timeout 0
>   set login
>   enable chap
>   set log LCP
> 
> 
> i type "pptp vpn-sf.cnet.com cnet" to initiate the connection.  the log 
> file shows:
> 
> Jan 31 16:19:22 cluttered ppp[32201]: Phase: Using interface: tun0
> Jan 31 16:19:22 cluttered ppp[32201]: Phase: deflink: Created in closed state
> Jan 31 16:19:23 cluttered ppp[32201]: LCP: FSM: Using "deflink" as a transport
> Jan 31 16:19:23 cluttered ppp[32201]: LCP: deflink: State change Initial 
> --> Closed
> Jan 31 16:19:23 cluttered ppp[32201]: LCP: deflink: State change Closed --> 
> Stopped
> Jan 31 16:19:24 cluttered ppp[32201]: LCP: deflink: LayerStart
> Jan 31 16:19:24 cluttered ppp[32201]: LCP: deflink: SendConfigReq(1) state 
> = Stopped
> Jan 31 16:19:24 cluttered ppp[32201]: LCP:  ACFCOMP[2]
> Jan 31 16:19:24 cluttered ppp[32201]: LCP:  PROTOCOMP[2]
> Jan 31 16:19:24 cluttered ppp[32201]: LCP:  ACCMAP[6] 0x
> Jan 31 16:19:24 cluttered ppp[32201]: LCP:  MRU[4] 1500
> Jan 31 16:19:24 cluttered ppp[32201]: LCP:  MAGICNUM[6] 0x451f9b67
> Jan 31 16:19:24 cluttered ppp[32201]: LCP:  AUTHPROTO[5] 0xc223 (CHAP 0x05)
> Jan 31 16:19:24 cluttered ppp[32201]: LCP: deflink: State change Stopped 
> --> Req-Sent
> Jan 31 16:19:25 cluttered ppp[32201]: LCP: deflink: RecvConfigReq(77) state 
> = Req-Sent
> Jan 31 16:19:25 cluttered ppp[32201]: LCP:  MRU[4] 1500
> Jan 31 16:19:25 cluttered ppp[32201]: LCP:  ACCMAP[6] 0x000a
> Jan 31 16:19:25 cluttered ppp[32201]: LCP:  AUTHPROTO[5] 0xc223 (CHAP 0x81)
> Jan 31 16:19:25 cluttered ppp[32201]: Warning: CHAP 0x81 not supported
> Jan 31 16:19:25 cluttered ppp[32201]: LCP:  MAGICNUM[6] 0x2567e117
> Jan 31 16:19:25 cluttered ppp[32201]: LCP:  PROTOCOMP[2]
> Jan 31 16:19:25 cluttered ppp[32201]: LCP:  ACFCOMP[2]
> Jan 31 16:19:25 cluttered ppp[32201]: LCP: deflink: SendConfigNak(77) state 
> = Req-Sent
> Jan 31 16:19:25 cluttered ppp[32201]: LCP:  AUTHPROTO[5] 0xc223 (CHAP 0x05)
> Jan 31 16:19:25 cluttered ppp[32201]: LCP: deflink: SendTerminateReq(1) 
> state = Req-Sent
> Jan 31 16:19:25 cluttered ppp[32201]: LCP: deflink: State change Req-Sent 
> --> Closing
> Jan 31 16:19:25 cluttered ppp[32201]: LCP: deflink: LayerFinish
> Jan 31 16:19:25 cluttered ppp[32201]: LCP: deflink: State change Closing 
> --> Initial
> 
> and i'm not connected.  the tech support people at my company are not very 
> helpful.  they said, use windows.  i can get it to work fine from windows 
> but it's so annoying (it interrupts existing connections and forces 
> everything to go through the vpn regardless of whether it makes any 
> sense).  it used to work great with freebsd...  any help appreciated!!
> 
> thanks
> -jsd-

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: MPD Server ?

[Brian Somers]

> mpd does not know how to be a pppoe server.
> HOWEVER the pppoed program is designed to turn the normal ppp
> into a server. It is possible that archie might be able to 
> make mpd use pppoed (or embed it) but I'm pretty sure he hasn't done
> it yet.

pppoed can be told to run mpd.  As long as mpd can handle treating 
descriptor 0 as it's link, it'll work.

> MPD Is a multilink server, yes.

When a second link is established from a client, it'll invoke a new 
mpd instance.  Is mpd smart enough to detect this and pass the link 
from one invocation to the other ?

This was one of the trickiest parts of making ppp(8) a multilink 
server.

> On Wed, 20 Feb 2002, ome ome wrote:
> 
> > Hi.
> > 
> > I would like to test a multi-link over 2 different
> > types of device with MPD 3.7 (PPPoE and PPP over a
> > serial link) between two stations on freeBSD 3.5.
> > 
> > MPD works fine as client, so I would like to know if
> > MPD 3.7 could be a server PPPoE? Moreover, could MPD
> > be
> > a multi-link server?
> > 
> > Thanks in advance.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

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

[Brian Somers]

> > "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  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)

  - Install the latest version of ppp from http://www.Awfulahk.org/ppp.html

> --
> Matt Emmerton

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

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

[Brian Somers]

> Brian Somers wrote:
> | > > "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
> | > > | >
> | > > | 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)
> | 
> |   - Install the latest version of ppp from http://www.Awfulahk.org/ppp.html
> 
> OK, I'll grab it and give it a try.
> 
> Will it be OK to install that on a 4.1-RELEASE box?

Should be.

> Should I still use the following lines in my ppp.conf?
> 
> set mru 1492
> set mtu 1492

These shouldn't be required any more.

> Thanks in advance,
> 
> Greg

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Your change to in.c to limit duplicate networks is causing trouble

[Brian Somers]

I've crossposted to -net and -arch as this could probably do with a 
review from a larger audience....

> Brian Somers writes:
> | > In message: <[EMAIL PROTECTED]>
> | > Joerg Wunsch <[EMAIL PROTECTED]> writes:
> | > : As Alan Clegg wrote:
> | > : 
> | > : > Is there any motion to pull this back?
> | > : 
> | > : There was only consensus to special-case the BOOTP case.
> | > : 
> | > : As i understand it, the change itself was more than desirable for
> | > : PPP connections (so no surprise it was Brian who committed it).
> | > 
> | > dhclient is still broken, however.  The 0.0.0.0 should be the special
> | > case, not bootp.
> | 
> | Yes, I agree.
> | 
> | The question is should interface address assignments with 
> | destinations of 0.0.0.0 have host routes created in the first place ?
> | 
> | I'd tend to think not.
> | 
> | Doing this will make things consistent, but maybe at the expense of 
> | breaking something else - under ``usual'' circumstances.  I'm 
> | thinking along the lines of some program that may configure a 
> | destination address of 0.0.0.0 and then expect to be able to do stuff 
> | with the routing table - such as adding a route via 0.0.0.0 or calling 
> | sendto() or connect() with 0.0.0.0 as the destination.
> | 
> | I'm guessing that dhclient will continue to work without a host route 
> | as it writes raw IP packets, and I haven't heard of any problems with 
> | running multiple dhclients using the old in.c code where second and 
> | subsequent SIOCAIADDRs with a 0.0.0.0 destination had no host route.  
> | I haven't tested it yet though.
> | 
> | If nobody objects, I'll tweak things so that destinations of 0.0.0.0 
> | don't add host routes and see if it breaks anything I know of.  I'll 
> | post patches to -arch and cc -net when I get something working.
> 
> Sounds reasonable.  I can test it when you have something since I'm hitting
> this on a few machines around here.
> 
> Doug A.

The attached patches seem to make things work for BOOTP with multiple 
interfaces and for ppp expecting failures for duplicate destination 
address assignments.

The code now avoids adding a host route if the interface address is 
0.0.0.0, and always treats a failure to add a host route as fatal 
(previously, it masked EEXIST for some reason - I guessed because it 
was trying to handle address re-assignment, but that works ok with 
this patch).

If people could get some time to review it, it'd be appreciated.

Cheers.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  

Index: netinet/in.c
===
RCS file: /home/ncvs/src/sys/netinet/in.c,v
retrieving revision 1.63
diff -u -r1.63 in.c
--- netinet/in.c1 Apr 2002 21:31:06 -   1.63
+++ netinet/in.c4 Apr 2002 16:52:59 -
@@ -661,7 +661,7 @@
 {
register u_long i = ntohl(sin->sin_addr.s_addr);
struct sockaddr_in oldaddr;
-   int s = splimp(), flags = RTF_UP, error;
+   int s = splimp(), flags = RTF_UP, error = 0;
 
oldaddr = ia->ia_addr;
ia->ia_addr = *sin;
@@ -723,17 +723,21 @@
return (0);
flags |= RTF_HOST;
}
-   if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0)
-   ia->ia_flags |= IFA_ROUTE;
 
-   if (error != 0 && ia->ia_dstaddr.sin_family == AF_INET) {
-   ia->ia_addr = oldaddr;
-   return (error);
+   /*
+* Don't add routing table entries for interface address entries
+* of 0.0.0.0.  This makes it possible to assign several such address
+* pairs with consistent results (no host route) and is required by
+* BOOTP.
+*/
+   if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY) {
+   if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) {
+   ia->ia_addr = oldaddr;
+   return (error);
+   }
+   ia->ia_flags |= IFA_ROUTE;
}
 
-   /* XXX check if the subnet route points to the same interface */
-   if (error == EEXIST)
-   error = 0;
 
/*
 * If the interface supports multicast, join the "all hosts"



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

Re: Userland ppp hung in Ack-Rcvd

[Brian Somers]

> I observed a peculiar situation today on an ADSL link using pptpclient
> and the userland ppp daemon: the LCP negociation hunk in state
> Ack-Rcvd for almost 3 hours (until I killed it) without any progress,
> but without timing out, either.
> 
> Here is an excerpt from the log:
> 
> Apr  3 05:25:02 melusine ppp[53064]: tun0: LCP: deflink: State change Initial --> 
>Closed
> Apr  3 05:25:02 melusine ppp[53064]: tun0: LCP: deflink: State change Closed --> 
>Stopped
> Apr  3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: LayerStart
> Apr  3 05:25:03 melusine ppp[53064]: tun0: Warning: deflink: Reducing configured MRU 
>from 1500 to 1480
> Apr  3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = 
>Stopped
> Apr  3 05:25:03 melusine ppp[53064]: tun0: LCP:  ACFCOMP[2]
> Apr  3 05:25:03 melusine ppp[53064]: tun0: LCP:  PROTOCOMP[2]
> Apr  3 05:25:03 melusine ppp[53064]: tun0: LCP:  ACCMAP[6] 0x
> Apr  3 05:25:03 melusine ppp[53064]: tun0: LCP:  MRU[4] 1480
> Apr  3 05:25:03 melusine ppp[53064]: tun0: LCP:  MAGICNUM[6] 0x91e371fe
> Apr  3 05:25:03 melusine ppp[53064]: tun0: LCP: deflink: State change
> Stopped --> Req-Sent
> Apr  3 05:25:06 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = 
>Req-Sent
> Apr  3 05:25:06 melusine ppp[53064]: tun0: LCP:  ACFCOMP[2]
> Apr  3 05:25:06 melusine ppp[53064]: tun0: LCP:  PROTOCOMP[2]
> Apr  3 05:25:06 melusine ppp[53064]: tun0: LCP:  ACCMAP[6] 0x
> Apr  3 05:25:06 melusine ppp[53064]: tun0: LCP:  MRU[4] 1480
> Apr  3 05:25:06 melusine ppp[53064]: tun0: LCP:  MAGICNUM[6] 0x91e371fe
> Apr  3 05:25:09 melusine ppp[53064]: tun0: LCP: deflink: SendConfigReq(1) state = 
>Req-Sent
> Apr  3 05:25:10 melusine ppp[53064]: tun0: LCP:  ACFCOMP[2]
> Apr  3 05:25:10 melusine ppp[53064]: tun0: LCP:  PROTOCOMP[2]
> Apr  3 05:25:10 melusine ppp[53064]: tun0: LCP:  ACCMAP[6] 0x
> Apr  3 05:25:10 melusine ppp[53064]: tun0: LCP:  MRU[4] 1480
> Apr  3 05:25:10 melusine ppp[53064]: tun0: LCP:  MAGICNUM[6] 0x91e371fe
> Apr  3 05:25:10 melusine ppp[53064]: tun0: LCP: deflink: RecvConfigAck(1) state = 
>Req-Sent
> Apr  3 05:25:10 melusine ppp[53064]: tun0: LCP: deflink: State change Req-Sent --> 
>Ack-Rcvd
> Apr  3 08:11:27 melusine ppp[53064]: tun0: Phase: Signal 15, terminate.
> 
> In other sessions that I have a trace of, I never enter Ack-Recvd,
> but instead:
> 
> Apr  3 08:12:07 melusine ppp[61776]: tun0: LCP: deflink: RecvConfigReq(224) state = 
>Req-Sent
> 
> This box is running 4.5-STABLE kernel and world cvsuppsed 10 days or so
> ago. Any idea why it did not time out?
> 
> Thomas.

It looks like the peer responded to our req, but never sent a req of 
it's own.  In this scenario, ppp should enter Ack-Rcvd from Req-Sent 
due to the RCA event and initialise it's restart counter.  Examining 
the code implies that it's doing this (FsmRecvConfigAck() in fsm.c).

Therefore something else must have jammed things up.  If you have a 
diagnostic socket configured, it's worth using pppctl to connect to 
it and see if that wakes up ppp - or at least if ``show timer'' 
indicates that the timers are running (run ``show timer'' a few times 
and note the timeouts decrementing).

If it doesn't wake things up or you can't connect, killing ppp with a 
-11 and examining the core dump is the only option but you'll 
need symbols in the binary.  I add CFLAGS=-g and STRIP= to the 
Makefile to achieve this.

> -- 
> [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Your change to in.c to limit duplicate networks is causing trouble

[Brian Somers]

> As Brian Somers wrote:
> 
> > The code now avoids adding a host route if the interface address is 
> > 0.0.0.0, and always treats a failure to add a host route as fatal 
> > (previously, it masked EEXIST for some reason - I guessed because it 
> > was trying to handle address re-assignment, but that works ok with 
> > this patch).
> 
> I think that will be fatal for the sppp case with dynamic IP
> address negotiation.  We use 0.0.0.0 as the local IP address
> for the unnegotiated PPP link then, with the idea that it's
> still possible to route through the interface anyway.  For
> dial-on-demand PPP links (like on ISDN), the routed packets
> will then trigger the dialout event.  In the course of the
> PPP negotiations, an actual local IP address will be negotiated
> and assigned, but we first need some packets to pass through the
> PPP layer in order to trigger this.
> 
> Perhaps it would still be possible to use per-interface routes
> even after your change (-iface isp0 etc.), but currently, a number
> of documents describe that it's possible to use local address
> 0.0.0.0 and still get normal routing behaviour for those links.

Hmm, valid point :(

So the code will have to become something like the attached ?  This 
is quite grotty, but I can't think of any clean way other than 
somehow telling SIOCAIFADDR and SIOCSIFADDR not to add the host route 
in the first place.

> -- 
> cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL
> 
> http://www.sax.de/~joerg/NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  

Index: in.c
===
RCS file: /home/ncvs/src/sys/netinet/in.c,v
retrieving revision 1.63
diff -u -r1.63 in.c
--- in.c1 Apr 2002 21:31:06 -   1.63
+++ in.c4 Apr 2002 23:18:36 -
@@ -661,7 +661,7 @@
 {
register u_long i = ntohl(sin->sin_addr.s_addr);
struct sockaddr_in oldaddr;
-   int s = splimp(), flags = RTF_UP, error;
+   int s = splimp(), flags = RTF_UP, error = 0;
 
oldaddr = ia->ia_addr;
ia->ia_addr = *sin;
@@ -723,17 +723,25 @@
return (0);
flags |= RTF_HOST;
}
-   if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0)
-   ia->ia_flags |= IFA_ROUTE;
 
-   if (error != 0 && ia->ia_dstaddr.sin_family == AF_INET) {
-   ia->ia_addr = oldaddr;
-   return (error);
+   /*-
+* Don't add host routes for interface addresses of
+* 0.0.0.0 --> 0.255.255.255 netmask 255.0.0.0.  This makes it
+* possible to assign several such address pairs with consistent
+* results (no host route) and is required by BOOTP.
+*
+* XXX: This is ugly !  There should be a way for the caller to
+*  say that they don't want a host route.
+*/
+   if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY ||
+   ia->ia_netmask != IN_CLASSA_NET ||
+   ia->ia_dstaddr.sin_addr.s_addr != htonl(IN_CLASSA_HOST)) {
+   if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) {
+   ia->ia_addr = oldaddr;
+   return (error);
+   }
+   ia->ia_flags |= IFA_ROUTE;
}
-
-   /* XXX check if the subnet route points to the same interface */
-   if (error == EEXIST)
-   error = 0;
 
/*
 * If the interface supports multicast, join the "all hosts"



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

Re: Your change to in.c to limit duplicate networks is causing trouble

[Brian Somers]

> > The code now avoids adding a host route if the interface address is 
> > 0.0.0.0, and always treats a failure to add a host route as fatal 
> > (previously, it masked EEXIST for some reason - I guessed because it 
> > was trying to handle address re-assignment, but that works ok with 
> > this patch).
> 
> 
> One effect of the masked EEXIST is to suppress the spurious error
> which occurs when adding an alias IP address (SIOCAIFADDR) on the
> same logical subnet as an existing IP address. Users have no way
> of knowing that it's actually safe to simply ignore the error in
> that situation, so the masking should probably be preserved.

Hmm, thanks for the pointer.

I think this now works - where it didn't before (although see 
the new patch posted in response to Joergs mention of the sppp 
problem).

The lack of the EEXIST hack in my patch means that this will work as 
before:

ifconfig dc0 inet 172.16.0.5 netmask 0xff00
ifconfig dc0 inet 172.16.0.11 netmask 0xfff8

Where connections to 172.16.0.1-172.16.0.7 and 172.16.0.16-172.16.0.255 
come from 172.16.0.5 and connections to 172.16.0.8-172.16.0.15 come from 
172.16.0.11.

After the above however,

ifconfig dc0 inet 172.16.0.14 netmask 0xfff8

will (correctly) fail in the patched code.  It fails because the 
gateway/netmask combination produces a duplicate key in the routing 
table, returning an error from rtinit().  Previously, this failure 
was masked by the EEXIST hack, allowing the interface address update 
without a corresponding host route.

I believe the old behaviour becomes obviously wrong when someone then 
deletes the 172.16.0.11 interface address, blowing away the 
associated host route and leaving no routing table entry to talk to 
the 172.16.0.14 address.

So I don't think the old was was really safe after all :-/

>Stephen
> --
> Stephen Macmanus #include 
> [EMAIL PROTECTED]
> 
> - - - if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0)
> - - - ia->ia_flags |= IFA_ROUTE;
>  
> - - - if (error != 0 && ia->ia_dstaddr.sin_family == AF_INET) {
> - - - ia->ia_addr = oldaddr;
> - - - return (error);
> + /*
> +  * Don't add routing table entries for interface address entries
> +  * of 0.0.0.0.  This makes it possible to assign several such address
> +  * pairs with consistent results (no host route) and is required by
> +  * BOOTP.
> +  */
> + if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY) {
> + if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) {
> + ia->ia_addr = oldaddr;
> + return (error);
> + }
> + ia->ia_flags |= IFA_ROUTE;
>   }
>  
> - - - /* XXX check if the subnet route points to the same interface */
> - - - if (error == EEXIST)
> - - - error = 0;
>  
>   /*
>* If the interface supports multicast, join the "all hosts"

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: Your change to in.c to limit duplicate networks is causing trouble

[Brian Somers]

> > > > The code now avoids adding a host route if the interface address is 
> > > > 0.0.0.0, and always treats a failure to add a host route as fatal 
> > > > (previously, it masked EEXIST for some reason - I guessed because it 
> > > > was trying to handle address re-assignment, but that works ok with 
> > > > this patch).
> > > 
> > > 
> > > One effect of the masked EEXIST is to suppress the spurious error
> > > which occurs when adding an alias IP address (SIOCAIFADDR) on the
> > > same logical subnet as an existing IP address. Users have no way
> > > of knowing that it's actually safe to simply ignore the error in
> > > that situation, so the masking should probably be preserved.
> > 
> > Hmm, thanks for the pointer.
> > 
> > I think this now works - where it didn't before (although see 
> > the new patch posted in response to Joergs mention of the sppp 
> > problem).
> > 
> > The lack of the EEXIST hack in my patch means that this will work as 
> > before:
> > 
> > ifconfig dc0 inet 172.16.0.5 netmask 0xff00
> > ifconfig dc0 inet 172.16.0.11 netmask 0xfff8
> > 
> > Where connections to 172.16.0.1-172.16.0.7 and 172.16.0.16-172.16.0.255 
> > come from 172.16.0.5 and connections to 172.16.0.8-172.16.0.15 come from 
> > 172.16.0.11.
> > 
> > After the above however,
> > 
> > ifconfig dc0 inet 172.16.0.14 netmask 0xfff8
> > 
> > will (correctly) fail in the patched code.  It fails because the 
> > gateway/netmask combination produces a duplicate key in the routing 
> > table, returning an error from rtinit().  Previously, this failure 
> > was masked by the EEXIST hack, allowing the interface address update 
> > without a corresponding host route.
> 
>  All true. However, this change just redefines the desired behavior
>  in this situation. The current EEXIST hack prevents a "meaningless"
>  error message (in the sense that it is still possible to use the
>  172.16.0.14 address due to the existence of the earlier route).
> 
>  This patch just restores the original behavior from earlier BSD
>  versions which reported an error for the reasons you mention.
> 
>  I guess it's just a judgement call as to which one is more desirable.
> 
> >I believe the old behaviour becomes obviously wrong when someone then 
> >deletes the 172.16.0.11 interface address, blowing away the 
> >associated host route and leaving no routing table entry to talk to 
> >the 172.16.0.14 address.
> >
> >So I don't think the old was was really safe after all :-/
> 
>  Definitely true. An ideal solution would involve some type of
>  reference count for the route entry to maintain connectivity
>  without attempting to add a duplicate route which would always
>  cause an error.
> 
>  It would be even easier if users didn't setup redundant addresses
>  like this one which serve no purpose! ;-) The people who do it,
>  however, are also the most likely to think the resulting error
>  indicates an actual problem with the new address assignment.

Well, it does serve a purpose - it allows the machine to accept 
tcp connections on the .14 address (although udp requests get nicely 
confused) and to bind to the .14 address before connect().

The resulting error *does* indicate that there's a problem with the 
new address assignment;  adding that .14 address with a conflicting 
netmask should be considered wrong (and is treated as an error when 
the EEXIST hack is removed).  If they want to add another address to 
the 172.16/28 subnet, they must use a netmask of 0x to get 
the desired result.

The EEXIST hack is just permitting people to confuse themselves.

>  Stephen
> 
> 
> --
> Stephen Macmanus #include 
> [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: (KAME-snap 6381) tun device & IPv6

[Brian Somers]

> Hi,
> 
> could someone with more knowledge of the tun device please take a look 
> at the code around line 387 in net/if_tun.c? It looks like tunoutput() 
> drops all packets here that aren't of the AF_INET family - most notably, 
> it drops IPv6 packets.
> 
> We hacked around this with the simple fix below, but I'm not sure if 
> there are any drawbacks...
> 
> --- if_tun.c.oldTue May 14 15:40:30 2002
> +++ if_tun.cTue May 14 15:48:15 2002
> @@ -384,7 +384,7 @@
>  *(u_int32_t *)m0->m_data = htonl(dst->sa_family);
>  } else {
>   #ifdef INET
> -   if (dst->sa_family != AF_INET)
> +   if (dst->sa_family != AF_INET && dst->sa_family != AF_INET6)
>   #endif
>  {
>  m_freem(m0);
> 
> Thanks,
> Lars
> -- 
> Lars Eggert <[EMAIL PROTECTED]>   USC Information Sciences Institute

If you look at the larger picture

if (tp->tun_flags & TUN_IFHEAD) {
/* Prepend the address family */
M_PREPEND(m0, 4, M_DONTWAIT);

/* if allocation failed drop packet */
if (m0 == NULL) {
ifp->if_iqdrops++;
ifp->if_oerrors++;
return (ENOBUFS);
} else
*(u_int32_t *)m0->m_data = htonl(dst->sa_family);
} else {
#ifdef INET
if (dst->sa_family != AF_INET)
#endif
{
m_freem(m0);
return (EAFNOSUPPORT);
}
}

The tun device, when given the TUNSIFHEAD ioctl, will prepend the 
address family.  If TUNSIFHEAD is turned off, it will drop non IPv4 
packets.

This was done for backwards compatibility.  To use IPv6 with tun, you 
must use the TUNSIFHEAD ioctl and prepend/strip the address family on 
the front of each packet (see bundle_Create() in 
src/usr.sbin/ppp/bundle.c).

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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

Re: misc/37696: Virtual hosts broken

[Brian Somers]

> Problem exists between keyboard and chair.
> The reason why ifconfig complains is that you're assigning a point-to-point 
> address to an ethernet interface and both addresses have the same 
> point-to-point address.
> 
> This is how you add ips to an interface:
> ifconfig xl0 192.168.1.1 netmask 255.255.255.0 # this is the primary
> ifconfig xl0 add 192.168.1.254 netmask 255.255.255.255 # All extra addresses 

You forgot ``alias''.

> within the same subnet MUST have netmask 0x or 255.255.255.255 to 
> prevent routing problems.

No, they must have a non-conflicting IP/mask combination.  A netmask 
of 0x will make it non-conflicting, and is usually what you 
mean, but it's also possible to

ifconfig xl0 192.168.1.1 netmask 255.255.255.0
ifconfig xl0 add 192.168.1.254 netmask 255.255.255.128 alias

which means that data sent to (say) 192.168.1.200 will go with a 
source IP of 192.168.1.254, and not 192.168.1.1.

> Baldur
> 
> On Friday 03 May 2002 05:39, you wrote:
> > >Number: 37696
> > >Category:   misc
> > >Synopsis:   Virtual hosts broken
> > >Confidential:   no
> > >Severity:   serious
> > >Priority:   high
> > >Responsible:freebsd-bugs
> > >State:  open
> > >Quarter:
> > >Keywords:
> > >Date-Required:
> > >Class:  sw-bug
> > >Submitter-Id:   current-users
> > >Arrival-Date:   Thu May 02 22:40:01 PDT 2002
> > >Closed-Date:
> > >Last-Modified:
> > >Originator: Dan Protich
> > >Release:4.6-PRERELEASE
> > >Organization:
> >
> > Shell-box Computers Inc.
> >
> > >Environment:
> >
> > bash-2.05a$ uname -a
> > FreeBSD sinister.shell-box.com 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #0:
> > Sat Mar  2 02:32:42 EST 2002
> > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386 bash-2.05a$
> >
> > >Description:
> >
> > Thought that i would upgrade freebsd box and main dns server was on it only
> > accepted 1 virtual host and not a 2nd and wouldnt allow manual add of vhost
> > rc.conf network information wouldn't accept did a upgrade from 4.5-release
> > also kernel upgrade.
> >
> > >How-To-Repeat:
> >
> >sinister# ifconfig vr0 66.118.153.201 66.118.153.255 alias
> > sinister# ifconfig vr0 66.118.153.254 66.118.153.255 alias
> > ifconfig: ioctl (SIOCAIFADDR): File exists
> > sinister#
> >  doesn't exist?
> >   sinister# ifconfig
> > vr0: flags=8843 mtu 1500
> > inet 66.118.153.66 netmask 0xff00 broadcast 66.118.153.255
> > inet6 fe80::207:95ff:fea8:153b%vr0 prefixlen 64 scopeid 0x1
> > inet 66.118.153.201 netmask 0xff00 broadcast 66.118.153.255
> > ether 00:07:95:a8:15:3b
> > media: Ethernet autoselect (100baseTX )
> > status: active
> > lp0: flags=8810 mtu 1500
> > sl0: flags=c010 mtu 552
> > faith0: flags=8002 mtu 1500
> > lo0: flags=8049 mtu 16384
> > inet6 ::1 prefixlen 128
> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
> > inet 127.0.0.1 netmask 0xff00
> > ppp0: flags=8010 mtu 1500
> > sinister#
> >
> > >Fix:
> > >
> > >Release-Note:
> > >Audit-Trail:
> > >Unformatted:

-- 
Brian <[EMAIL PROTECTED]><[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

Re: CCP does not work between Linux ppp client and FreeBSD ppp server

[Brian Somers]

Hi,

You're correct.  The linux machine should not REQ the compression 
schemes that were REJected.

> (This is a PPP related question.)
> 
> It seems the RedHat Linux 7.2 PPP client does not work with the FreeBSD =
> 4.5 PPP server in the CCP (Compression Control Protocol) negotiation. =
> Briefly, the problem looks like the following:
> 
> Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> =
> PPP server
> Linux <-- CCP conf reject (schemes, B and C) <-- PPP server
> (That is, the PPP server picked the compression scheme A, and rejected =
> the rest.)
> 
> Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> =
> PPP server
> Linux <-- CCP conf reject (schemes, B and C) <-- PPP server
> (repeat may times without progress.)
> 
> It seems the Linux client did not follow the PPP protocol and ignored =
> the CCP reject messages.
> The correct message exchange should look like the following:
> 
> Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> =
> PPP server
> Linux <-- CCP conf reject (schemes, B and C) <-- PPP server
>  ---> CCP conf request (scheme A) --> PPP server
> <---  CCP conf ACK (scheme A) <-- PPP server
> 
> Comments?
> 
> P.S. I am using PPPoE for the testing.

-- 
Brian <[EMAIL PROTECTED]><[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

Re: PPPoE performance difference

[Brian Somers]

Hi,

The performance problem here is due to deflate compression being 
used.  Compression is quite expensive (more so than decompression) 
and the slow machine is losing out here.

If you ``disable deflate pred1 mppe'' and ``deny deflate pred1 mppe'' 
you should see better results.

> I had a friend that was claiming that they were seeing poor PPPoE
> performance from FreeBSD 4.4 as compared to Win2K.  Since he is in
> Japan and I am in the US its a bit difficult to do hands on trouble
> shooting.  So I decided to set up my on PPPoE server and see if I
> could reduplicate any of his claims.  
> 
> I setup a 4.5-RELEASE box as my PPPoE server and a 4.5-STABLE box as
> my PPPoE client.  Both hosts are using Intel Pro 10/100 (fxp) nics.  
> The client is a relatively fast 999.72-MHz 686-class CPU.  The server
> is a slow 133.27-MHz 586-class CPU.
> 
> I am seeing a performance difference that I can't explain.  Coping of
> a large file (2.6MB) using scp to the server from the client takes
> about 7 seconds.  Coping the same file from the server to the client
> takes 14 seconds.  Any body have any idea why the two directions are
> so different?
> 
> BTW, copying the file over ethernet (not PPPoE) takes 3 seconds in
> both directions between the same hosts using the same nics.
> 
> The ppp.conf file for the server is:
> default:
> # set log Phase Chat LCP IPCP CCP tun command
>  enable mssfixup
>  set log error
>  ident user-ppp VERSION (built COMPILATIONDATE)
>  set dns 10.10.1.7 10.10.1.9
>  accept dns
>  allow users
>  enable chap
>  enable pap
>  set timeout 0
>  enable lqr
>  accept lqr
>  enable sroutes
> 
> gta3:
>  allow mode direct
>  set mru 1492
>  set mtu 1492
>  set speed sync
>  set ifaddr 10.199.2.1 10.199.2.110-10.199.2.200 255.255.255.255
> 
> For the client I used the following ppp.conf
> default:
>  set socket none
> 
> PPP0:
>  set redial 0 0
>  set timeout 0
>  set reconnect 20 5
>  set ifaddr 0.0.0.0/0 0.0.0.0/0
>  accept chap
>  disable pap
>  set authname testuser3
>  set authkey testpass
>  set ctsrts off
>  enable dns
>  set dns 10.0.0.1 10.0.0.2
>  resolv readonly
>  enable lqr
>  set lqrperiod 20
>  accept lqr
>  accept acfcomp
>  accept protocomp
>  accept pred1
>  accept vjcomp
>  set log error
>  set openmode active
>  enable mssfixup
>  set device PPPoE:fxp0:gta3
>  set speed sync
>  set dial
>  set cd 10
>  set login
>  set mru 1492
>  set mtu 1492
> 
> 
> Thanks for your time,
> Larry
> 
> 
> -- 
> 
> Larry Baird| http://www.gnatbox.com
> Global Technology Associates, Inc. | Orlando, FL
> Email: [EMAIL PROTECTED] | TEL 407-380-0220, FAX 407-380-6080

-- 
Brian <[EMAIL PROTECTED]><[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

Re: netgraph documentation?

[Brian Somers]

On Tue, 4 Jun 2002 10:13:17 -0700 (PDT), Archie Cobbs <[EMAIL PROTECTED]> wrote:
[.]
> I don't think you can have a point-to-point interface who's
> remote IP address is also local to your box. In other words,
> this may not work on the same machine but it might work if
> you use two different machines... can you try that?
> 
> -Archie

It's ok to do this.  I run ppp back-to-back with itself using

  set device "!ppp -direct in"

for testing.  In fact, there are examples in ppp.conf.sample :)

-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: problems with ifconfig aliases

[Brian Somers]

On Thu, 6 Jun 2002 17:36:31 -0700 (PDT), "Joe T." <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Originally, I had created some aliases with the following command:
> 
> # ifconfig dc0 alias 192.168.1.111 255.255.255.255
> # ifconfig dc0 alias 192.168.1.112 255.255.255.255

You forgot the netmask keyword.  The missing keyword means that it tries
to use 255.255.255.255 as the destination address and silently fails as
the interface isn't a pointopoint interface.

The failure is due to conflicting host route entries because you didn't
give the correct netmask.

-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: host routes for interface addresses

[Brian Somers]

On Fri, 7 Jun 2002 17:27:46 +0300 (EEST), Iasen Kostov <[EMAIL PROTECTED]> wrote:
> 
> 
> On Fri, 7 Jun 2002, Iasen Kostov wrote:
> 
> >
> >   I think it's possible to use SIOCSIFCAP to tell the kernel not to set
> > host route via IFCAP_NOROUTE or something similar which will set
> > IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit()
> > and if it is set no host route will be added. And ofcourse there should be
> > a way to set this by ifconfig ( -noroute for example).
> >   What you think about this ?
> >
>   Hum or set an iface flag IFF_NOROUTE in struct ifnet.if_flags by
> SIOCGIFFLAGS ioctl.
>   What you think ?

The problem is that ifnet::if_flags is a short and all of it's bits are
already used up :(

-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: host routes for interface addresses

[Brian Somers]

This certainly seems to make sense.  Could you generate a patch and send
it to me ?  I can test & commit it, and then maybe look at removing that
horrible BOOTP hack :)

I haven't looked at it yet, but it'll be worth testing that ifm_flags is
populated correctly in routing socket messages...

Thanks.

On Sat, 8 Jun 2002 18:33:44 +0300 (EEST), Iasen Kostoff <[EMAIL PROTECTED]>
wrote:
> 
> 
> On Sat, 8 Jun 2002, Brian Somers wrote:
> 
> > On Fri, 7 Jun 2002 17:27:46 +0300 (EEST), Iasen Kostov
> > <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > On Fri, 7 Jun 2002, Iasen Kostov wrote:
> > >
> > > >
> > > >   I think it's possible to use SIOCSIFCAP to tell the kernel not
> > > >   to set
> > > > host route via IFCAP_NOROUTE or something similar which will set
> > > > IFCAP_NOROUTE in uif_capenable. This flag will be checked in
> > > > in_ifinit() and if it is set no host route will be added. And
> > > > ofcourse there should be a way to set this by ifconfig (
> > > > -noroute for example).
> > > >   What you think about this ?
> > > >
> > >   Hum or set an iface flag IFF_NOROUTE in struct ifnet.if_flags by
> > > SIOCGIFFLAGS ioctl.
> > >   What you think ?
> >
> > The problem is that ifnet::if_flags is a short and all of it's bits
> > are already used up :(
> >
> > --
> > Brian <[EMAIL PROTECTED]>  
> > <[EMAIL PROTECTED]>
> >   <http://www.Awfulhak.org>   
> >   
> > Don't _EVER_ lose your sense of humour !  
> > 
> >
>   Yep but I think I solve the problem.
> 
> I found this in net/if.h :
> 
> /*
>  * The following flag(s) ought to go in if_flags, but we cannot change
>  * struct ifnet because of binary compatibility, so we store them in
>  * if_ipending, which is not used so far.
>  * If possible, make sure the value is not conflicting with other
>  * IFF flags, so we have an easier time when we want to merge them.
>  */
> 
> and decide to use if_ipending utill extend of if_flags.
> 
> Just add to the ifr_ifru union of the ifreq struct:
> int ifru_flagslong;
> and this:
> #define ifr_flagslong   ifr_ifru.ifru_flagslong /* long flags (int) */
> 
> than in net/if.c I've changed SIOCGIFFLAGS and SIOCSIFFLAGS handling
> in ifioctl() function like this:
> 
> case SIOCGIFFLAGS:
> flagslong = ifp->if_flags & 0x;
> ifr->ifr_flagslong = flagslong | ifp->if_ipending;
> break;
> 
> case SIOCSIFFLAGS:
> error = suser(p);
> if (error)
> return (error);
> ->  ifp->if_ipending = ifr->ifr_flagslong & 0x;
>   ...
> 
> than ofcourse I fixed and ifconfig's function setifflags() to use
> ifr_flagslong value instead of ifr_flags. It's a partial solution.
> Sysctl that returns iface table should do the same thing as
> SIOCGIFFLAGS handler. I saw that ifm_flags is int that means there
> will not be a problem when sysctl is returning the new flags. And I
> think this doesn't break anything in binary compatibility.
> 
> To test all this I add this 2 lines to cmds[] declaration in
> ifconfig.c :
> 
> { "noroute",IFF_NOROUTE,setifflags },
> { "-noroute",   -IFF_NOROUTE,   setifflags },
> 
> and this line to net/if.h :
> 
> #define IFF_NOROUTE 0x2 /* Interface doesn't need host
> #route. */
> 
> Than a fixed in.c and add a IFF_NOROUTE check in in_ifinit() :
> 
> ...
> if (!(ifp->if_ipending & IFF_NOROUTE))
> if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY ||
> ...
> 
> And everything work perfect for me on the test machine :
> 
> root@test:/sys/netinet on ttyp1
> #:> ifconfig ed0 10.0.0.0 netmask 255.255.0.0 noroute
> root@test:/sys/netinet on ttyp1
> #:> netstat -rn
> Routing tables
> Internet:
> DestinationGatewayFlagsRefs  Use  Netif
> Expire default212.36.8.137   UGSc04   
> ed1 127.0.0.1  127.0.0.1  UH  1   10   
> lo0 212.36.8/23link#2 UC  40   
> ed1
> 
> root@test:/sys/netinet on ttyp1
> #:> ifconfig ed0 10.0.0.0 netmask 255.255.0.0 -noroute
> root@test:/sys/netinet on ttyp1
> #:> netstat -rn
> Routing tables
> Internet:
> DestinationGatewayFlagsRefs  Use  Netif
> Expire default212.36.8.137   UGSc04   
> ed1 10/16  link#1 UC  00   
> ed0 127.0.0.1  127.0.0.1  UH  1   10   
> lo0 212.36.8/23link#2 UC  30   
> ed1
> 
>   Could it be done that way, what You think ?
> 
-- 
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

Re: host routes for interface addresses

[Brian Somers]

On Sat, 8 Jun 2002 21:53:59 +0300 (EEST), Iasen Kostov <[EMAIL PROTECTED]> wrote:
>   Here is the patch. I'm now looking in the code to see where kernel
> replays to the interface table requests. I hope there are not a lot
> of places where it sets ifm_flags.
[.]

I think you forgot to add the patch :*P

-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: Problems with PPP and one annoying ISP

[Brian Somers]

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]>
  
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

Re: digiboard pc/8i

[Brian Somers]

What does dgb say when you boot with -v ?

I have one of these boards here - it worked last time I tried it

On Thu, 13 Jun 2002 23:08:53 +0700 (WIT), hantu <[EMAIL PROTECTED]> wrote:
> 
> 
> On Thu, 13 Jun 2002, Jonathan Lemon wrote:
> 
> > In article [EMAIL PROTECTED]> 
>you write:
> > >
> > >dear ,..
> > >i have old digiboard card pc/8i adapter, but my freebsd can't detect it :(
> > >i'm using fbsd 45R
> > >i was compile new kernel with add line with this :
> > >OPTIONS NDGBPORTS=8
> > >OPTIONS COM_MULTIPORT
> > >device dgb0
> > >
> > >i can't write "device dgb0 at isa? bla... bla...
> > >because if i write this my kernel can't be compile with error message " no
> > >isa ... bla.. bla.. on that line".
> >
> > Make sure that you have "device isa0" in your config file as well.
> > --
> > Jonathan
> >
> 
> the problem was fix it but, still can't detect digiboard :(
> any suggestion ?
> 
> thanks
> 
> regards
> saaal

-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: NFS - exports syntax

[Brian Somers]

On Sun, 14 Jun 2009 10:29:21 +0200 "marco\.borsati...@poste\.it" 
 wrote:
> Hi to all.
> My problem concerns NFS configuration. I'm trying to simulate a little 
> network using Sun VirtualBox in a Windows host and most of operations work 
> fine, but I've some problems with /etc/exports syntax.
> This is my current exports file:
> --
> /cond1 /cond2 -mapall=user1 pc01 pc02
> /usr/home -alldirs pc01 pc02
> ---
> When I type:
> #showmount -e
> I get
> /usr/home     pc02 pc02
> /cond1            pc01 pc02
> /cond2            pc01 pc02
> which is ok. But I wold like to use different "mapall" options for different 
> filesystems; for example, something like this:
> /usr/home -alldirs        pc02 pc02
> /cond1 -mapall=user2 /cond2 -mapall=user1 pc01 pc02
> which does not work: only /usr/home is exported. Or
> /usr/home        pc02 pc02
> /cond1 -mapall=user2 pc01 pc02
> /cond2 -mapall=user1 pc01 pc02
> Only /usr/home and /cond1 are exported.
> FreeBSD exports man page states:
> "Each line in the file (other than comment lines that begin with a #) 
> specifies the mount point(s) and export flags within one local server file 
> system for one or more hosts.". So, is it impossible to export different 
> directories to different users using mapping?
> Thanks. Sorry for my bad english.
> Marco

FreeBSD's exports implementation will only allow you to associate
mount options per local filesystem per remote machine, so this
version:

> /usr/home        pc02 pc02
> /cond1 -mapall=user2 pc01 pc02
> /cond2 -mapall=user1 pc01 pc02

is correct, but only if /cond1 and /cond2 are different filesystems.
If they're the same, this won't work.

Maybe you do something clever with exporting nullfs versions
of them and adding those to exports, but I haven't tried that.

-- 
Brian Somers  
Don't _EVER_ lose your sense of humour !   
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: NFS - exports syntax

[Brian Somers]

On Mon, 15 Jun 2009 18:46:35 +0200, "marco\.borsati...@poste\.it" 
 wrote:
> First, thank you for your help.
> 
> 
> 
> >
> > FreeBSD's exports implementation will only allow you to associate
> > mount options per local filesystem per remote machine, so this
> > version:
> >
> > > /usr/home        pc02 pc02
> > > /cond1 -mapall=user2 pc01 pc02
> > > /cond2 -mapall=user1 pc01 pc02
> >
> > is correct, but only if /cond1 and /cond2 are different filesystems.
> > If they're the same, this won't work.
> > 
> 
> /cond1 and /cond2 are folders under root on /dev/ad0s1a; this is the reason 
> whi my exports does not work.

Yes.

> So should I do something like this:
> #mkdir /usr/shared/cond1
> #mkdir /usr/shared/cond2
> (this is, I think, a better choice also from different points of view).
> (exports)
> /usr/shared -alldirs pc01 pc02 (or -network 192.168.0)
> (mount for different users)
> #mount _nfs server:/usr/shared/cond1 /mnt/for-user-1
> #mount _nfs server:/usr/shared/cond2 /mnt/for-user-2
> 
> But, if this sintax is correct, how can I use mapall option?

Your exports file should say:
/usr/shared/cond1 -maproot=whatever pc01
/usr/shared/cond2 -maproot=somethingelse pc02

The two entries for the same physical filesystem are fine as
long as you don't atempt to duplicate the remote host.

-- 
Brian Somers   
Don't _EVER_ lose your sense of humour !
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: NTP - default /etc/ntp.conf

[Brian Somers]

On Thu, 09 Jul 2009 10:20:29 +0100, David Malone  wrote:
> The NTP pool guys have set up our vendor domain. I'd like to commit
> the patch below to ntp.conf. It does the following:
> 
>   1) Uses our vendor domain at the pool.
>   2) Points people at the pool website and encourages
>  people to provide a server in the pool (as a
>  courtesy to the pool guys).
>   3) Fixes a spelling.
>   4) Comments out the local clock and includes a link
>  to documentation for use of the local clock on
>  the ntp.org site.
> 
> If there are no objections, I'll ask re@ for permission to commit
> this.
> 
>   David.
> 
> Index: ntp.conf
> ===
> --- ntp.conf(revision 195484)
> +++ ntp.conf(working copy)
> @@ -13,19 +13,22 @@
>  #
>  # The following three servers will give you a random set of three
>  # NTP servers geographically close to you.
> -# See http://en.wikipedia.org/wiki/NTP_pool for details.
> +# See http://www.pool.ntp.org/ for details. Note, the pool encourages
> +# users with a static IP and good upstream NTP servers to add a server
> +# to the pool. See http://www.pool.ntp.org/join.html if you are interested.
>  #
>  # The option `iburst' is used for faster initial synchronisation.
>  # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD.
>  #
> -server 0.pool.ntp.org iburst maxpoll 9
> -server 1.pool.ntp.org iburst maxpoll 9
> -server 2.pool.ntp.org iburst maxpoll 9
> +server 0.freebsd.pool.ntp.org iburst maxpoll 9
> +server 1.freebsd.pool.ntp.org iburst maxpoll 9
> +server 2.freebsd.pool.ntp.org iburst maxpoll 9
> +#server 3.freebsd.pool.ntp.org iburst maxpoll 9
>  
>  #
>  # If you want to pick yourself which country's public NTP server
>  # you want sync against, comment out the above servers, uncomment
> -# the next ones and replace CC with the country's abbrevation.
> +# the next ones and replace CC with the country's abbreviation.
>  # Make sure that the hostnames resolve to a proper IP address!
>  #
>  # server 0.CC.pool.ntp.org iburst maxpoll 9
> @@ -50,10 +53,12 @@
>  #restrict 127.127.1.0
>  
>  #
> -# If we lose sync against all configured servers, the NTP clients
> -# syncing against this server will lose sync too. To overcome this,
> -# we will act as a stratum 10 server with our own internal clock
> -# so that everybody at least will have the same time as we have.
> +# If a server loses sync with all upstream servers, NTP clients
> +# no longer follow that server. The local clock can be configured
> +# to provide a time source when this happens, but it should usually
> +# be configured on just one server on a network. For more details see
> +# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock
> +# The use of Orphan Mode may be preferable.
>  #
> -server 127.127.1.0
> -fudge 127.127.1.0 stratum 10
> +#server 127.127.1.0
> +#fudge 127.127.1.0 stratum 10

I'd tend to suggest stratum 13 so that the inattentive admin
doesn't spread his potentially dodgy clock info too far when
he tries uncommenting the above  otherwise I (rather
subjectively) agree with this change :)

-- 
Brian Somers   
Don't _EVER_ lose your sense of humour !
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ppp command port does not listens on ipv4 unless no INET6 in kernel

[Brian Somers]

On Sun, 17 Sep 2006 20:10:47 +0900 Hajimu UMEMOTO <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> >>>>> On Thu, 14 Sep 2006 15:44:18 +0200 (CEST)
> >>>>> "Julian Stacey" <[EMAIL PROTECTED]> said:
> 
> jhs> I'm not clear if this is a bug or a config error:
> jhs> It seems though my /usr/sbin/ppp was moving traffic
> jhs> to & from internet, it was only listening for commands
> jhs> (not data) on ipv6, not ipv4, thus I could not type commands
> jhs> like dial & drop, unless instead of running ppp -auto
> jhs> instead I invoked ppp manually in foreground on localhost.
> 
> As far as I read the source of ppp(8), it only listen on an IPv6, and
> expects to listen on an IPv4 through an IPv4-mapped IPv6 address.
> However, an IPv4-mapped IPv6 address feature is disabled by default.
> ppp(8) should be rewritten to listen on both an IPv4 and an IPv6.
> But, it is slightly complex.  So, I made a patch to enable an
> IPv4-mapped IPv6 address only for the socket that ppp(8) is listening
> on.
> I have no environment for testing this.  Could you try this patch?
> 
> Index: usr.sbin/ppp/server.c
> diff -u -p usr.sbin/ppp/server.c.orig usr.sbin/ppp/server.c
> --- usr.sbin/ppp/server.c.origSun Sep  5 10:46:52 2004
> +++ usr.sbin/ppp/server.c Sun Sep 17 19:54:43 2006
> @@ -346,6 +346,13 @@ server_TcpOpen(struct bundle *bundle, u_
>  goto failed;
>}
>  
> +#ifndef NOINET6
> +  if (probe.ipv6_available) {
> +int off = 0;
> +setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&off, sizeof(off));
> +  }
> +#endif
> +
>setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &s, sizeof s);
>if (bind(s, (struct sockaddr *)&ss, sz) < 0) {
>  log_Printf(LogWARN, "Tcp: bind: %s\n", strerror(errno));
> 
> 
> Sincerely,

AFAIR I had trouble getting that code to work and was advised at
the time that I'd just get the mapped port for free.  I haven't
been using IPv6 on production machines for some time, so I haven't
seen the problem :(

It'd be great if you'd commit the patch if Julian says it works
ok for him.

Cheers.

-- 
Brian Somers  <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !   <[EMAIL PROTECTED]>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Download speed and TCPIP window sizing

[Brian Somers]

On Thu, 31 May 2007 22:06:39 +0800 Pang <[EMAIL PROTECTED]> wrote:
>   Could anyone tell me whether my understanding on Window sizing 
> correct? Also, is there any way to alter the window sizing in freebsd or 
> apache?

AFAIK you can't increase the window size unless you use
the tcp wscale option (it's a 2-byte value).  This wasn't
possible 'till recently in -current:

andre   2007-02-01 17:39:19 UTC

  FreeBSD src repository

  Modified files:
sys/netinet  tcp_syncache.c tcp_usrreq.c 
  Log:
  Change the way the advertized TCP window scaling is computed.  Instead of
  upper-bounding it to the size of the initial socket buffer lower-bound it
  to the smallest MSS we accept.  Ideally we'd use the actual MSS information
  here but it is not available yet.
  
  For socket buffer auto sizing to be effective we need room to grow the
  receive window.  The window scale shift is determined at connection setup
  and can't be changed afterwards.  The previous, original, method effectively
  just did a power of two roundup of the socket buffer size at connection
  setup severely limiting the headroom for larger socket buffers. 

  Tested by:  many (as part of the socket buffer auto sizing patch)
  MFC after:  1 month
  
  Revision  ChangesPath
  1.104 +8 -2  src/sys/netinet/tcp_syncache.c
  1.143 +7 -2  src/sys/netinet/tcp_usrreq.c

This may not be MFC'd (I think I'd object if it was)
as there are several old OpenBSD/pf setups that have
issues with wscale > 4.  Hopefully these setups will
be fixed by the time 7.0 is released, as windows/vista
and linux/debian now set wscale > 4 too.

The patch is pretty small though, so you may want to
try applying it to your box to see if it helps.

HTH.

-- 
Brian Somers  <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !   <[EMAIL PROTECTED]>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bug in userland PPP LQR?

[Brian Somers]

On Wed, 11 Jul 2007 19:14:03 -0600 Brett Glass <[EMAIL PROTECTED]> wrote:
> At 06:23 PM 7/11/2007, Mike Tancsa wrote:
>  
> >Did you try and use just LCP echo mode instead ?  I have come across a
> >number of devices (especially GPRS/EVDO cards) that seem to say yes to
> >supporting LQR, but do not.  Try instead lcp echo
> 
> I will try it. (To be more specific, I am going to try 
> 
> disable lqr
> allow lqr

accept lqr

> enable echo
> echoperiod 12

set echoperiod 12

> so that the peer can get LQR if it requests it.) But since this would 
> just be working around the bug I think might be there, it would also 
> be a good idea to look at how the LQR counter is managed. From what
> I can see, the problem is that the counter either is cumulative or
> counts irrevocably up to 5 after one LQR packet is missed. The
> reason why I'd like to see more eyes than my own on this is that
> it's difficult to see how and where the LQR routines are invoked
> and how they react to a pattern of missed and un-missed packets.

I'd also add "set log +lqm" to your configuration.

Disabling lqr should just remove the problem as there
will be no calls to SendLqrReport().

Try adding the lqm logging with lqr enabled too.
It'd be interesting to see what's actually being
sent out.

I expect unacknowledged LQR packets to be resent
5 times (exactly the same packet), and the 6th
timeout to cause a line drop.

The spec says that the peer may ignore an LQR
request if it's under load, but that it must
respond to a duplicate LQR request.  My suspicion
is that some implementations just ignore LQR
altogether under load.  These implementations
should disable LQR if they can't implement it
properly.

Of course the *other* option is to implement an
LQM strategy.  I've never come up with anything
that might really be useful though - except for
suggesting that LQR is disabled.

-- 
Brian Somers  <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !   <[EMAIL PROTECTED]>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: tun devices and vpnc in CURRENT

[Brian Somers]

On Sun, 22 Apr 2007 13:18:49 +0200 Stefan Ehmann <[EMAIL PROTECTED]> wrote:
> On CURRENT, each time I stop/start vpnc a new tun device is created.
> Since I restart vpnc every time I re-connect to the network, my ifconfig 
> output fills up with tun devices.
> 
> On 6.2-RELEASE the tun0 device is reused each time I run vpnc.
> 
> Reverting to src/sys/net/if_tun.c rev 1.162 shows the old behaviour. (It 
> seems 
> I'm noticing this a bit late)
> 
> Is this a bug in either CURRENT or vpnc?
> 
> If I set sysctl net.link.tun.devfs_cloning=0, vpnc doesn't work at all:
> # vpnc
> vpnc version 0.4.0
> kldload: can't load if_tun: File exists
> can't initialise tunnel interface: No such file or directory
> 
> This is a CURRENT as of today. Please tell me if you need more info.

It looks like the problem is in the vpnc-script destroy_tun_device()
function, but even if I add FreeBSD to that, it creates the additional
interfaces.  Maybe this is because I'm passing it bogus data and the
connection attempt doesn't cleanup properly either.

Have you tried talking to the port writer or maintainer?

-- 
Brian Somers  <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !   <[EMAIL PROTECTED]>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bug in userland PPP LQR?

[Brian Somers]

On Sat, 14 Jul 2007 13:01:06 -0600 Brett Glass <[EMAIL PROTECTED]> wrote:
> At 12:41 PM 7/14/2007, Brian Somers wrote:

> >I expect unacknowledged LQR packets to be resent
> >5 times (exactly the same packet), and the 6th
> >timeout to cause a line drop.
> 
> That's what I thought too. But it seems as if a
> single dropped packet among plenty of successful
> ones can cause the session to drop. This is
> why I am wondering if the counter is properly reset
> or if one missed packet leads to a permanent loss
> of synchronization.

The lqm logging should prove/disprove that ppp
is sending the packet 6 times.

The code *looks* ok.  The counter is reset at line
236 of lqr.c (on receipt of an LQR packet).

-- 
Brian Somers  <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !   <[EMAIL PROTECTED]>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: tun devices and vpnc in CURRENT

[Brian Somers]

On Sun, 15 Jul 2007 11:04:18 +0200 Stefan Ehmann <[EMAIL PROTECTED]> wrote:
> On Saturday 14 July 2007 21:21:32 Brian Somers wrote:
> > On Sun, 22 Apr 2007 13:18:49 +0200 Stefan Ehmann <[EMAIL PROTECTED]> wrote:
> > > On CURRENT, each time I stop/start vpnc a new tun device is created.
> > > Since I restart vpnc every time I re-connect to the network, my ifconfig
> > > output fills up with tun devices.
> > >
> > > On 6.2-RELEASE the tun0 device is reused each time I run vpnc.
> > >
> > > Reverting to src/sys/net/if_tun.c rev 1.162 shows the old behaviour. (It
> > > seems I'm noticing this a bit late)
> > >
> > > Is this a bug in either CURRENT or vpnc?
> > >
> > > If I set sysctl net.link.tun.devfs_cloning=0, vpnc doesn't work at all:
> > > # vpnc
> > > vpnc version 0.4.0
> > > kldload: can't load if_tun: File exists
> > > can't initialise tunnel interface: No such file or directory
> > >
> > > This is a CURRENT as of today. Please tell me if you need more info.
> >
> > It looks like the problem is in the vpnc-script destroy_tun_device()
> > function, but even if I add FreeBSD to that, it creates the additional
> > interfaces.  Maybe this is because I'm passing it bogus data and the
> > connection attempt doesn't cleanup properly either.
> >
> > Have you tried talking to the port writer or maintainer?
> 
> No.
> 
> I haven't checked if a "ifconfig tunX destroy" works on the commandline. That 
> should reveal the source of the problem.
> 
> If this works, the problem shouldn't be it if_tun code. Unfortunately, I have 
> no working CURRENT setup ATM, so I can't test it.

Well, I can confirm that 'ifconfig tunN destroy' works ok and
has done for some time now.  I can also demonstrate that vpnc
itself is opening the lowest available tun device by running
it with garbage values.

Perhaps the author should be told that FreeBSD can destroy
interfaces and they'll take it from there?

-- 
Brian Somers  <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !   <[EMAIL PROTECTED]>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: tracking down strange MTU issues with PPPoE)

[Brian Somers]

Perhaps adding

  set mtu max 1452

will help ?

On Tue, 18 Jun 2002 16:54:49 -0400, Mike Tancsa <[EMAIL PROTECTED]> wrote:
> 
> The DSL whole supplier we use (Bell Canada) has been turfing their Redback 
> SMSes and moving to an ERX from unisphere networks.
> 
> With the Redback, all was great... I had a FreeBSD box acting as a NAT 
> gateway for a number of Windows boxes and all was great.  Then, the 
> customer got moved over to one of these ERXes and there is now some strange 
> MTU problem.  Couple of things.  Supposedly the default MTU on the ERX is 
> 1472 (or 1452) depending on who you talk to and not 1492.
> 
> e.g. when doing a fetch to
>  >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
>  >> Attempting to fetch from http://lynx.isc.org/current/.
> Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C
> 16682 bytes transferred in 89.5 seconds (186.41 Bps)
> fetch: transfer interrupted
> 
> Notice the speed... Its totally brutal. yet, a transfer from just a few 
> hops away is fine.
> 
> My question is, how can I track this problem down ?  There seems to be some 
> strange interaction with FreeBSD because if I put a Windows box on the 
> other end, it does not suffer from this same problem. I can easily repeat 
> the problem, but the question is, how can I track down the issue and then 
> explain it to my telco.
> 
> (Note, I have tried various MTU and MRU settings.
> 
> Thanks for any pointers.
> 
> 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18
> 
> 
> default:
>   set log Phase Chat LCP IPCP CCP tun command
>   ident user-ppp VERSION (built COMPILATIONDATE)
> 
>   # Ensure that "device" references the correct serial port
>   # for your modem. (cuaa0 = COM1, cuaa1 = COM2)
>   #
>   set device /dev/cuaa1
> 
>   set speed 115200
>   set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
> \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
>   set timeout 180# 3 minute idle timer (the default)
>   enable dns # request DNS info (for resolv.conf)
> 
> 
> pppoe:
>   set device PPPoE:fxp1
>   #set mtu 1452
>   #set mru 1452
>   set speed sync
>   enable lqr
>   set lqrperiod 5
>   set cd 5
>   set dial
>   set login
>   set timeout 0
>   disable deflate pred1 mppe
>   deny deflate pred1 mppe
>   set authname [EMAIL PROTECTED]
>   set authkey thepassword
>   set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
>   add default HISADDR
> 
> 
> 
>   ---Mike
> 
> Mike Tancsa,tel +1 519 651 3400
> Sentex Communications,  [EMAIL PROTECTED]
> Providing Internet since 1994www.sentex.net
> Cambridge, Ontario Canada   www.sentex.net/mike
> 


-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: ppp callback-question

[Brian Somers]

I think I already answered this, but you should be able to

  set redial 3

to reduce the timeout.

On Tue, 18 Jun 2002 17:41:50 +0200, Michael Bretterklieber wrote:
> Hi,
> 
> I have a dialin-Box with FreeBSD 3.5. I use the callback (cbcp) option 
> from ppp and the problem is, that ppp waites about 30 seconds until he 
> starts the callback.
> Is there any option to reduce this timeout?
> 
> bye,
> -- 
> --
> --
> E-mail: [EMAIL PROTECTED]
> 
> JAWA Management Software GmbH
> Liebenauer Hauptstr. 200
> A-8041 GRAZ
> Tel: ++43-(0)316-403274-12
> Fax: ++43-(0)316-403274-10
> GSM: ++43-(0)676-93 96 698
> homepage: http://www.jawa.at
> - privat ---
> E-mail:   [EMAIL PROTECTED]
> homepage: http://www.inode.at/mbretter
> --

-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: digiboard pc/8i ..

[Brian Somers]

What driver are you using, what version of FreeBSD and what devices ?

I've assuming the pc/8i is an ISA card ?  If so, you should be using
the dgb driver and /dev/cuaDxx in both -stable and -current...

On Thu, 20 Jun 2002 23:09:33 +0700 (WIT), hantu wrote:
> 
> hello all
> 
> i have digiboard pc/8i adapter,...
> i try to check all the port using command tip
> if i put modem on port 1, the port 1 run well, the other drop .. only can
> be connected but can't put modem command like AT or something else.
> 
> please help me,..
> 
> thanks
> -oo-

-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: More pppoe debugging info

[Brian Somers]

On Sat, 22 Jun 2002 17:24:23 -0400, Andrew Lankford wrote:
> 
> Below is my final attempt at documenting my problems using the latest stable
> ppp/netgraph combo with my DSL modem and 3Com 3c905C-TX ethernet card: 
> 
> Looks like the NGM_PPPOE_<11> (hook "M-^HM-^V^H^Hh ^K^H")  string
> no longer bears any resemblance to the session id bytes.  
> 
> Sorry for not making sure all the text is wrapped  properly, but I
> figure that would make it only harder to read.
> 
> Andrew Lankford
[.]
> PPP.LOG:
[.]
> Jun 22 16:40:58 bogushost2 ppp[334]: tun0: Phase: deflink: dial -> carrier 
> Jun 22 16:41:01 bogushost2 ppp[334]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook 
>"RES-6400-3-NRP2") 
> Jun 22 16:41:02 bogushost2 ppp[334]: tun0: Phase: Received NGM_PPPOE_<11> (hook 
>"M-^HM-^V^H^Hh ^K^H") 

These not-terminated strings have now been fixed.  I don't believe
they're the source of the problem though.

[.]
> TCPDUMP OUTPUT:
> 
> 
> 16:40:58.645213 PPPoE PADI [Host-Uniq UTF8]
> 16:41:00.643094 PPPoE PADI [Host-Uniq UTF8]
> 16:41:00.673124 PPPoE PADO [Host-Uniq UTF8] [Service-Name] [AC-Name 
>"RES-6400-3-NRP2"] [AC-Cookie UTF8]
> 16:41:00.673173 PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name 
>"RES-6400-3-NRP2"]
> 16:41:00.739685 PPPoE PADS [ses 0x9688] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name 
>"RES-6400-3-NRP2"]
> 16:41:00.758209 PPPoE  [ses 0x9688] LCP 20: Conf-Req(69), MRU=1492, Auth-Prot PAP, 
>Magic-Num=cca2f534
> 16:41:02.757866 PPPoE  [ses 0x9688] LCP 20: Conf-Req(70), MRU=1492, Auth-Prot PAP, 
>Magic-Num=cca2f534
> 16:41:03.695201 PPPoE PADT [ses 0x9688] [Generic-Error "session closed"]
[.]

Can you try the latest version (committed about an hour ago) and add a
-e to the tcpdump command and repost your findings ?

Cheers.

-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: Issues with pppoe & FBSD 4.6

[Brian Somers]

Hi,

The problem has now been fixed.  It was caused because of a bug in ppp where
it would only read at most one netgraph message per second.  The additional
(unused) message was adding another second - pushing things over the edge.

You can either get the latest ppp from http://www.Awfulhak.org/~brian, or
upgrade to the latest -stable or -current to fix the problem.

Oh, and my apologies for the amount of time it took to fix :(

On Tue, 25 Jun 2002 16:13:11 -0500 (CDT), [EMAIL PROTECTED] wrote:
> Any progress on this?  Just curious.  My fbsd box has been down for the
> last 36 hours.  Until yesterday it would be down for 8-10 hours then come
> up from 16-24.  Yesterday it went down at ~8:30 am and has been down
> since.  I left it try and grab IP information but it just "session closed"
> error (and created a shit load of logs).
> 
> 
> I copied my config files from my firewall and attempted to make one of my 2
> other fbsd boxes my firewall and connect up to the pppoe server but they
> had the same thing (timeout...Generic "session closed" errors). So it's
> definatly a fbsd issue.
> 
> Just wondering on the status...roomates are kinda getting ansy about
> getting the internet connection up and stable, after being up and down for
> about a week.
> 
> 
> rwz
> 
> 


-- 
Brian <[EMAIL PROTECTED]>   <[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

Re: minor bug in user ppp?

[Brian Somers]

Yep, that's a bug... feel free to apply the patch.

Cheers.

On Wed, 21 Jan 2004 13:01:52 -0800, Brooks Davis <[EMAIL PROTECTED]> wrote:
> I'm reviewing uses of sdl->sdl_data so see if I can make a minor change
> to the way that data is stored and I noticed what I think is a bug in
> the userland ppp implementation.  It looks like it's trying to print the
> interface name from the sdl, but the precision specifier is wrong.  A
> simpiler printf a little ways above this one appears to be correct.  I'm
> I correct that this is a bug?  See the patch below.
> 
> -- Brooks
> 
> Index: usr.sbin/ppp/arp.c
> ===
> RCS file: /usr/cvs/src/usr.sbin/ppp/arp.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 arp.c
> --- usr.sbin/ppp/arp.c16 Jan 2002 14:03:51 -  1.44
> +++ usr.sbin/ppp/arp.c21 Jan 2004 20:49:42 -
> @@ -302,7 +302,7 @@ arp_EtherAddr(int s, struct in_addr ipad
>  if ((ifa->sin_addr.s_addr & netmask->sin_addr.s_addr) ==
>  (ipaddr.s_addr & netmask->sin_addr.s_addr)) {
>log_Printf(verbose ? LogPHASE : LogDEBUG,
> - "Found interface %.*s for %s\n", dl->sdl_alen,
> + "Found interface %.*s for %s\n", dl->sdl_nlen,
>   dl->sdl_data, inet_ntoa(ipaddr));
>memcpy(hwaddr, dl, dl->sdl_len);
>free(buf);
> 
> -- 
> Any statement of the form "X is the one, true Y" is FALSE.
> PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
> 


-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PPPoE

[Brian Somers]

On Mon, 21 Jun 2004 01:44:09 -0700 (PDT), Yohan <[EMAIL PROTECTED]> wrote:
> Gleb,
> 
> Thanks for the reply. i have attached my ppp.conf and
> ppp.log as requested. I have tried setting carrier /
> ctsrts on/off and various other permutations /
> combinations. The best i proceeded till is ...
> Jun 19 13:00:26 chennai ppp[178]: tun0: Phase:
> Received NGM_PPPOE_ACNAME (hook "BANYAN") 

This seems to be the only message that the pppoe node is passing back to
ppp.  ppp is waiting for NGM_PPPOE_{SUCCESS,FAIL,CLOSE}.

> Jun 19 13:00:26 chennai ppp[178]: tun0: Debug: Waiting
> for carrier 
[.]

And until it gets NGM_PPPOE_{SUCCESS,FAIL,CLOSE}, ppp will stay waiting
for carrier.

I'd suggest you have a look at what traffic is being passed back and forth
on the wire - it might indicate what's going on.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PPPoE

[Brian Somers]

On Mon, 21 Jun 2004 05:55:41 -0700 (PDT), Yohan <[EMAIL PROTECTED]> wrote:
> 17:48:15.035656 0:8:a1:5f:b5:4b Broadcast 8863 60:
> PPPoE PADI [Host-Uniq UTF8]
> 17:48:15.049217 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
> PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
> [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
> UTF8]
> 17:48:15.049232 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
> PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
> "BANYAN"]

And the missing bit is the PADS packet (which we're expecting from the
PPPoE server).  Here, the netgraph node is resending the PADR after 2
seconds of inactivity, then dropping back to sending a PADI all over
again.

Interestingly enough, the PADR doesn't seem to have the Service-Name
or Relay-Session-ID tags that the PADO has - perhaps that's what's
causing the problem...  certainly the PADO handling code that sends
the PADS calls scan_tags() which is supposed to copy tags not already
handled from the PADO into the PADR.

Julian, have you any comments on this ?

Cheers.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Squid, FreeBSD, Multilink PPP

[Brian Somers]

On Wed, 30 Jun 2004 12:43:14 +0300, Gregory Edigarov <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> I have Squid-2.5 running on FreeBSD 5-Current. We have 2 ppp links,
> and use them in multilink mode, through userlevel ppp.
> If one or both links fail and then come up, say, if I just turn the
> modem power off and on all the  web browsing becomes very slow
> squid.
> It takes forever for squid to show a page which, in a normal
> conditions, would take only a few seconds. Pings to those sites I am
> trying to open are just fine.
> Taking squid down and then up have no effect. The only thing help is
> rebooting
> the whole system.
> 
> Is there anything I can do?

How does ppp deal with the link loss - does it notice immediately ?  I
would expect very little latency if it does as it should be able to just
trash the existing queued data and continue using the other link.

I guess other connections suffer the same problems -- it's not just squid ?

It might be interesting doing a ``show mp'' or ``show bundle'' to determine
what sort of packet queuing and reassembly is happening after the link is
lost.

If the queues are large, you might get slightly better performance by
reducing the links mtu (set mtu max), but really, things should recover
ok even with a ~1500 MTU.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PPPoE

[Brian Somers]

On Tue, 6 Jul 2004 01:32:43 -0700 (PDT), Yohan <[EMAIL PROTECTED]> wrote:
> The connection hangs invariably after 8 - 10 hours. It
> resumes after i kill the ppp process and redial. Could
> it be because the isp is re-assingning my IP. How do i
> automatically renew my IP with the ISP's DHCP server.

Try ``enable lqr'' in your ppp config.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PPPoE problem: "Too many LQR packets lost"

[Brian Somers]

On Sat, 24 Jul 2004 17:29:21 -0400, Mike Tancsa <[EMAIL PROTECTED]> wrote:
> On Sat, 24 Jul 2004 12:47:26 +1000, in sentex.lists.freebsd.net you
> wrote:
> 
> >
> >I found Mike Tancsa's patch but didn't like it.  I rolled my own, which
> >seems to be working so far.  It works by switching from LQR to simple
> >echo requests when LQR times out.
> 
> I feel so unliked ;-)   Seriously though, mine was a very ugly hack to
> get things working again for me.   Most of the DSL aggregators here
> are Juniper ERXes which do not play nice with FreeBSD's PPPoE.
> 
> >
> >(This is a patch against ppp in FreeBSD 4.8.  I haven't tried the ppp in
> >-current yet as -current is still a wild and woolly place that scares me.)
> 
> I think Brian re worked the LQR portion at least from looking at the
> commit messages
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/ppp/
> 
> It seems he will be MFC'ing his changes in another week or so.
> 
>   ---Mike

Yes, that's the plan.  I'd like you guys to test the new LQR stuff when
I MFC if you can.

I think there are good arguments for having more than one LQR failure policy
(disconnect when the peer doesn't respond), so I'll probably implement
something like this when the latest stuff has been tested.

Cheers.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Racoon breakage with recent kernel - what NOT to do

[Brian Somers]

On Wed, 14 Jul 2004 20:52:48 +0200, Hannes Mehnert <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
> On Mon, Jul 12, 2004 at 03:32:18PM -0600, Mike Durian wrote:
> > This is just a follow-up to say the problem still exists in a -current
> > system I built from source yesterday (7/11/04).  Does anyone know
> > what's going on?
> > 
> > And to clarify, the URL listed above does show the same problem I'm
> > seeing.
> 
> A workaround is setting MSIZE to 320 in your kernel config:
> options   MSIZE=320

Well, I applied this tweak to my kernel config file (some time ago!) and
it fixed the racoon issue **BUT** doing this badly breaks dtom() - all
sorts of issues turn up when a data pointer can't be turned back into its
owning mbuf pointer.

This explains all of the mis-aligned mbuf frees that turn up and panic the
system.

In fact, I can't really explain *why* dtom() actually works, but that's the
content of my other posting

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

uma_zcreate() call from kern_mbuf.c - bug?

[Brian Somers]

I'm a bit confused by this uma_zcreate() call in kern_mbuf.c:

zone_mbuf = uma_zcreate("Mbuf", MSIZE, mb_ctor_mbuf, mb_dtor_mbuf,
NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_MAXBUCKET);

Given that dtom() is defined as:

#define dtom(x) ((struct mbuf *)((intptr_t)(x) & ~(MSIZE-1)))

shouldn't this mean that the uma_zcreate should be:

zone_mbuf = uma_zcreate("Mbuf", MSIZE, mb_ctor_mbuf, mb_dtor_mbuf,
NULL, NULL, MSIZE - 1, UMA_ZONE_MAXBUCKET);

Of course m_get() et. al. seem to manage to get MSIZE aligned pointers back
from uma_zalloc_arg(zone_mbuf...) anyway, but surely that's an implementation
side effect and the align argument should be corrected.

There should probably also be a KASSERT here to ensure that MSIZE is sane (and
to stop idiots like me from shooting themselves in the foot with ``options
MSIZE=320'').

Comments on this patch ?

Index: kern_mbuf.c
===
RCS file: /home/ncvs/src/sys/kern/kern_mbuf.c,v
retrieving revision 1.3
diff -u -r1.3 kern_mbuf.c
--- kern_mbuf.c 2 Aug 2004 00:18:35 -   1.3
+++ kern_mbuf.c 9 Sep 2004 20:24:46 -
@@ -131,11 +131,15 @@
 mbuf_init(void *dummy)
 {
 
+   /* Ensure that MSIZE doesn't break dtom() */
+   KASSERTMSIZE - 1) ^ MSIZE) + 1) >> 1 == MSIZE,
+   ("Invalid MSIZE - must only have a single bit set"));
+
/*
 * Configure UMA zones for Mbufs, Clusters, and Packets.
 */
zone_mbuf = uma_zcreate("Mbuf", MSIZE, mb_ctor_mbuf, mb_dtor_mbuf,
-   NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_MAXBUCKET);
+   NULL, NULL, MSIZE - 1, UMA_ZONE_MAXBUCKET);
zone_clust = uma_zcreate("MbufClust", MCLBYTES, mb_ctor_clust,
mb_dtor_clust, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_REFCNT);
if (nmbclusters > 0)


-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Racoon breakage with recent kernel - what NOT to do

[Brian Somers]

On Thu, 9 Sep 2004 22:01:42 +0200, Hannes Mehnert <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
> On Thu, Sep 09, 2004 at 08:29:55PM +0100, Brian Somers wrote:
> > On Wed, 14 Jul 2004 20:52:48 +0200, Hannes Mehnert <[EMAIL PROTECTED]> wrote:
> > > On Mon, Jul 12, 2004 at 03:32:18PM -0600, Mike Durian wrote:
> > > > This is just a follow-up to say the problem still exists in a -current
> > > > system I built from source yesterday (7/11/04).  Does anyone know
> > > > what's going on?
> > > > 
> > > > And to clarify, the URL listed above does show the same problem I'm
> > > > seeing.
> > > 
> > > A workaround is setting MSIZE to 320 in your kernel config:
> > > options   MSIZE=320
> > 
> > Well, I applied this tweak to my kernel config file (some time ago!) and
> > it fixed the racoon issue **BUT** doing this badly breaks dtom() - all
> > sorts of issues turn up when a data pointer can't be turned back into its
> > owning mbuf pointer.
> 
> I'm currently using MSIZE=512 and get no panic.

Yes, MSIZE=512 works as it contains only one set bit.  MSIZE=320 doesn't
because there are two bits set.  I've posted my other message to -net
with a better description.

Cheers.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  <http://www.Awfulhak.org>   <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"