Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Mon, Feb 18, 2002 at 11:35:54PM -0800, Crist J. Clark wrote: > On Mon, Feb 18, 2002 at 08:43:45PM -0800, Archie Cobbs wrote: > > Crist J. Clark writes: > > > No, RFC1122 is a set of requirements for hosts implementing _the > > > Internet protocol._ > > > > OK... > > > > > > By your argument, the kernel should also block admin attempts to > > > > configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an > > > > interface. That would put a lot of people behind NAT boxes out of > > > > business. > > > > > > There are no requirements or references to RFC1918, 10.0.0.0/8, > > > 172.16.0.0/12, or 192.168.0.0/16 in RFC1122. > > > > Obviously, because 1918 > 1122. But I don't understand your point. > > :) Good point. I meant references to the subject matter of > RFC1918. (Not that RFCs don't frequently reference other RFCs with > numbers greater than theirs.) > > > My point is that if it's a private network, you can do whatever > > you want -- standards that were created to make machines on the > > same network interoperate don't apply to X if X is on a separate > > network. > > You can always do what you want. No one says you have to use the > Internet protocol to have your systems communicate. > > > There are real people with valid reasons for doing "weird" things, > > for testing or whatever, on private networks. We shouldn't make > > life hard for them. > > I have no problem making life easy for them. > > > If your host sends a 127/8 packet, I'd say chances are better than > > 90% that you intentionally configured it to do so. > > Exactly. I don't think anyone has a problem with letting people > configure their machines to do something pathological like sending > loopback packets outside of a host. But a stock system, that is, one > out of the box, should be compliant with the Standard and NOT do > this. > > > Note that "normal" people will still get the standard configuration > > which prevents transmitting 127/8 packets, as it has for many years, > > without this new change. > > No, as I have had to repeat many times, a stock FreeBSD system did NOT > behave properly in this respect. Take a stock FreeBSD system before > the change, sniff the default route, and type, > > $ ping 127.0.0.2 > > And watch the loopback packets head out onto the wire. > I fully agree. Or yet worse, ping -S 127.0.0.1 1.2.3.4 which could not be fixed by just adding a route to -net 127. > > So I don't see what the conflict is here, or why this extra check, > > which adds complexity and confusion, is needed. > > I'd personally prefer someone just fix lo0 so that, > > $ ifconfig lo0 inet 127.0.0.1 > > Actually added the route, > > 127127.0.0.1 UGSc00lo0 > > Like, > > $ ifconfig lo0 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff00 > > Would imply, but it doesn't. I started digging into the code to see > about fixing this, but no one seems to be sure if this brokeness is > intentional or not, so I never got too enthusiastic. > Nothing is broken here, we only add ARP routes by default. > Short of fixing this, blocking 127/8 in the kernel makes life a little > harder for those who want to do exotic things on their own nets, but > it does prevent the leakage. > What people neglect to see and comment on is that 127/8 was already disallowed unconditionally by in_canforward() for about 15 years. > > > > If someone intentionally configures their machine in an unconventional > > > > way, why automatically assume they are doing something wrong? > > > > > > > > My vote is to not have any special cases in the kernel for 127/8... > > > > rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing > > > > in the kernel. > > > > > > You definately want to at least block incoming 127.0.0.1 in the > > > kernel. Not doing so is a big security hole. Let's revisit that > > > discussion all over again, > > > > > > http://www.securityfocus.com/archive/1/166648 > > > > Yes, of course. We're talking about sending, not receiving, > > packets though. > > But what's the point of sending them if systems can't receive them? If > you need to remove five lines ip_input.c to get them in the machine, > why not just remove the same five from ip_output.c too (not that > in_canforward(), in.c, hasn't blocked loopback packets for even longer > than the input and output routines). > > One more time, my opinion on the best balance between having a default > compliant system, but something people can do whatever kinky things > they want in the privacy of their own ASs is (and the coding for > this is trivial... once I find where the heck the loopback isn't being > configured): > > 1) Remove the ip_output.c code blocking 127/8 destinations once the > lo0 puts a route for 127/8 into the routing table. > Not enough to block packets originated from 127/8, see above. > 2) Put a sysctl(8) wrapper on the ip_input.c check, > net.inet.ip.
Re: Ethernet bonding/load balancing on fbsd 4-stable
On Sun, 17 Feb 2002, Zviratko wrote: > [SNIP] > > I will try that, but I guess default route has precedence over ipfw. Not in the case of ipfw fwd. The routing decision seems to be made before ipfw fwd changes the packet. Nick Rogness <[EMAIL PROTECTED]> - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Tue, Feb 19, 2002 at 10:25:13AM +0200, Ruslan Ermilov wrote: > On Mon, Feb 18, 2002 at 11:35:54PM -0800, Crist J. Clark wrote: [snip] > > I'd personally prefer someone just fix lo0 so that, > > > > $ ifconfig lo0 inet 127.0.0.1 > > > > Actually added the route, > > > > 127127.0.0.1 UGSc00lo0 > > > > Like, > > > > $ ifconfig lo0 > > lo0: flags=8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff00 > > > > Would imply, but it doesn't. I started digging into the code to see > > about fixing this, but no one seems to be sure if this brokeness is > > intentional or not, so I never got too enthusiastic. > > > Nothing is broken here, we only add ARP routes by default. OK, so that's a reason we do not get the route. If we stick with that as proper behavior, I would then assert that this, > > $ ifconfig lo0 > > lo0: flags=8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff00 ^^ Information is at worst incorrect, and at best merely misleading and useless. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mpd-netgraph as VPN client to Cisco 2500
On Mon, 18 Feb 2002, Archie Cobbs wrote: > Unfortunately, there is no fix for this yet. However you can > try one trick, which is to set up a host route to the remote > IP address via your default gateway. I'm not sure if this will > work but it might (please report success/failure if you try it). Very happy to report that this works. I'm a happy VPN camper. - Justin -- [EMAIL PROTECTED] |"Don't sweat it -- http://hawkins.dropbear.id.au | it's only 1's and 0's" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
NAT
Hello, I have been doing some perfomance tests using the standard NAT implementation for FreeBsd, and also using NAT-PT, with the KAME implementation. In throughput and delay terms, the results are much worse for NAT4. May that result be due to the overloading introduced by ALG in the standard implementation? Maybe it has to analyse the packets deeper?? Thanks in advance. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
D-Link DWL-A520 support
Hi, I have a wireless PCI card D-Link DWL-A520. I haven't managed to find out any information about the support of this card by FreeBSD. 1. Does FreeBSD support D-Link DWL-A520 cards and if the answer is 'yes', via which driver? 2. The DWL-A520 card supports IEEE 802.11a standart for wireless communication and my ISP have Cisco Access Points, which support IEEE 802.11b standart. Will DWL-A520 card work with this Access Points or not? any ideas? Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: D-Link DWL-A520 support
I'm going to make a correction. The model of the card is not DWL-A520, but DWL-520. In that case the question #2 is not more valid. I know it's answer. Sorry for the mistake! Vladimir On Tue, 19 Feb 2002 16:11:51 +0200 Vladimir Terziev <[EMAIL PROTECTED]> wrote: > > Hi, > > I have a wireless PCI card D-Link DWL-A520. I haven't managed to find out any >information about the support of this card by FreeBSD. > > 1. Does FreeBSD support D-Link DWL-A520 cards and if the answer is 'yes', via >which driver? > 2. The DWL-A520 card supports IEEE 802.11a standart for wireless communication >and my ISP have Cisco Access Points, which support IEEE 802.11b standart. Will >DWL-A520 card work with this Access Points or not? > > any ideas? > > Vladimir > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Bpf interface discussion
Hi
I found one problem. Current bpf interface allows to work only with
one link layer type
during interface life time, but some network drivers such as SPPP or
NETGRAPH support
many link layer types and link layer type could be changed during
interface life time.
I suggest to add new function to bpf interface like this:
void bpfsetdlt (struct ifnet *ifp, u_int dlt) {
struct bpf_if*bp;
for (bp = bpf_iflist; bp != NULL; bp = bp->bif_next) {
if (ifp == bp->bif_ifp)
break;
}
if (!bp)
return;
bp->bif_dlt = dlt;
}
Best regards,
Roman Kurakin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: network buffer problem
Sirs,
Thank you for the clarification about 'no buffer space available' .
First of all I want to bring a new flavor of a test I did.
Switched back using natd again, used ping -s 4096 www.bart.nl and off
course a 128k/bits winamp stream from digitally imported ;-) to see what
will happen.
I was impressed about not one 'no buffer space available' was printed from
ping.
Look at the result.
--- viaweb.vianetworks.nl ping statistics ---
1943 packets transmitted, 1939 packets received, 0% packet loss
round-trip min/avg/max/stddev = 206.312/308.874/1370.284/191.811 ms
Packet loss zero!!! Just by changing for ipnat back to using natd.
Netstat -m
1/160/16768 mbufs in use (current/peak/max):
1 mbufs allocated to data
0/52/4192 mbuf clusters in use (current/peak/max)
144 Kbytes allocated to network (1% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
This test must make a point right?
So using the ipdivert kernel implementations instead of ipnat from IPFILTER
would make such a difference strange right?
As you asked I would like to tell you about the result that will occur from
no buffer space available. Packet loss, a slow connection and at the end in
some cases 100% packet loss.
I checked proctime (top) values when testing natd and it was eating up only
5 to 8% max.
But it's not strange to me to see natd eating up 90% proctime after playing
a intensive network game for about 4 hours. So something is still pretty
wrong, but I don't know what to tweak or where to look. And natd only will
recover from killing it and restarting the daemon.
Tweaking recvspace or sendspace doesn't provide any solution it could screw
up things even more in my case, didn't noticed any result from it.
And as I can see we can put mpd on the sideline here because I think it's
not causing this behaviour I'm I right?
Or you think mpd is still the real pain in the ass generating all these
troubles.
Thanks in advance.
Marcel
At 17:24 18-02-2002 -0800, Luigi Rizzo wrote:
>Ok, I have refrained from jumping into this thread but
>the noise is increasing and I think some clarifications are
>really necessary now.
>
>First of all: at various levels in the protocol stack, when
>a packet cannot be forwarded to the next layer, more often
>than not a ENOBUFS error is returned, which is propagated back
>and then printed by perror() as "no buffer space available".
>
>One of this situations is when a dummynet pipe fills up. So the
>test you report below with dummynet is telling absolutely nothing,
>and certainly it does not show an error or configuration problem.
>
>Second: ping makes no use of tcp, so changing the
>net.inet.tcp.{sendspace,recvspace} values has no [direct] impact
>on the behaviour of your ping.
>
>What I suspect is happening is that mpd is saturating either
>the divert socket queue (if you look in netinet/ip_divert.c,
>this size is fixed to 64k), or the buffer on the "tun" interface.
>
>My understanding stops here... if you can summarise
>what is the problem you were having initially, maybe i
>can give more details.
>
> cheers
> luigi
>
>On Tue, Feb 19, 2002 at 01:43:41AM +0100, Marcel de Vries wrote:
>
> > Well it could be mpd, but my good old friend ;-) tested a view things.
> >
> > First he used DUMMYNET to simulate his ADSL connection in a LAN
> environment
> > (100baseT)
> >
> > So he put in some packet loss and bandwidth limitations on his LAN and
> > started pinging some hosts. He gets the same result of packets being lost
> > with the message 'no buffer space available'. So in this way mpd wasn't
> > used at all. This makes sense right. Could it be a configuration
> problem or
> > a really hard to think IP stack problem?
> >
> > He was very sure to me about not having these problems when using previous
> > versions of FreeBSD before release 4.5.
> >
> > I don't know if that's true.
> > And most of the IP traffic is no problem at all, things that definitely
> cut
> > the chase is to be generating a lot of UDP traffic like games do. This
> > buffer seems to be running wild from that type of traffic.
> >
> > Tonight we lowered the following value's
> > net.inet.tcp.sendspace: 16384
> > net.inet.tcp.recvspace: 16384
> >
> > We started gaming like for more then a hour and no problems at all.
> > But I think it was not long enough.
> >
> > But I hope this is useful: To recover from a total down of the internet
> > connection, I need to restart mpd. Mpd was patched to start the following
> > script when executed.
> >
> > #!/bin/sh
> > INTERFACE=$1
> > PROTOCOL=$2
> > LOCAL=$3
> > REMOTE=$4
> >
> > /sbin/route delete default
> > /sbin/ifconfig ng0 mtu 1492
> > /sbin/route add default $REMOTE
> >
> > [ -x /sbin/ipnat ] && /sbin/ipnat -CF -f /etc/ipnat.conf && ipf -y &&
> > echo -n 'ipnat'
> >
> > /usr/bin/killall -HUP inetd
> > /usr/bin/killall snort
> > /bin/sleep 15 && /usr/local/bin/snort -i ng0 -p -o -D -c
> > /u
RE: network buffer problem -/- natd
i too am currently looking into natd - it seems to eat more cpu as the number of connections it handles goes uip - not just the throughput. - i'm not an expert but truss, strace and grof show that most of the time is spent in sendto() ... ... i find this odd becuase recvfrom seems not to be so intensive. ps - can anyone tell me if the following assumption is correct: * if gprof, strace, etc show most of the time spent in sendto() then it immediately follows that this is what is using CPU time? * i know its a bit off topic but i could make a syscall which simpy sleeps, so shows up as taking time but isn;t doing much really? am i right? intY has automatically scanned this email with Sophos Anti-Virus (www.inty.com) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
Ruslan Ermilov writes: > > > Note that "normal" people will still get the standard configuration > > > which prevents transmitting 127/8 packets, as it has for many years, > > > without this new change. > > > > No, as I have had to repeat many times, a stock FreeBSD system did NOT > > behave properly in this respect. Take a stock FreeBSD system before > > the change, sniff the default route, and type, > > > > $ ping 127.0.0.2 > > > > And watch the loopback packets head out onto the wire. Yes this is broken.. but only IF you are using the normal configuration where 127.0.0.1/8 is configured on lo0. So the bug is in the kernel routing to the 127/8 network, which should be via lo0 instead of the default route. The fact that 127/8 is normally configured on lo0 is a policy matter. > I fully agree. Or yet worse, > > ping -S 127.0.0.1 1.2.3.4 > > which could not be fixed by just adding a route to -net 127. Wait!! If I specify "-S 127.0.0.1" then that's what I want! Besides, you could use "-S 0.1.2.3" or any of millions of other "illegal" source IP addresses -- do we need a special kernel hack to prevent those as well?? "-S" means "Kernel, use this source address and DON'T ARGUE!" > > But what's the point of sending them if systems can't receive them? If > > you need to remove five lines ip_input.c to get them in the machine, > > why not just remove the same five from ip_output.c too (not that > > in_canforward(), in.c, hasn't blocked loopback packets for even longer > > than the input and output routines). Here's one example: you are probing other machines for broken firewalls. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Ethernet bonding/load balancing on fbsd 4-stable
On Mon, Feb 18, 2002 at 01:44:05PM -0800, Sean Chittenden wrote: > > The only real "cisco only" protocol is the PAgP (Port Aggregation > > Protocol) which is essentially just a FEC auto-negiotation protocol they > > made up. AFAIK noone other then Cisco actually implements this though. > > Don't forget to add EIGRP and CDP to the list. -sc Woops, I ment the "cisco only"isms related to link aggregation. One could list Cisco proprietary protocols that don't work with other vendors for days and still not get them all. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: network buffer problem -/- natd
After 4 hours of pinging and listening to a shoutcast stream natd rised to his state of eating 34% proctime (top) Connection timed out, did a restart of mpd and everything is running normal agian. Bugs me. Grtz, Marcel At 15:40 19-02-2002 +, you wrote: > i too am currently looking into natd - it seems to eat more cpu as the >number of connections it handles goes uip - not just the throughput. > > - i'm not an expert but truss, strace and grof show that most of the time >is spent in sendto() ... > >... i find this odd becuase recvfrom seems not to be so intensive. > > ps - can anyone tell me if the following assumption is correct: > > * if gprof, strace, etc show most of the time spent in sendto() > then it immediately follows that this is what is using > CPU time? > > > * i know its a bit off topic but i could make a syscall which > simpy sleeps, > so shows up as taking time but isn;t doing much really? > >am i right? > > >intY has automatically scanned this email with Sophos Anti-Virus >(www.inty.com) > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mpd-netgraph as VPN client to Cisco 2500
Justin Hawkins writes: > > Unfortunately, there is no fix for this yet. However you can > > try one trick, which is to set up a host route to the remote > > IP address via your default gateway. I'm not sure if this will > > work but it might (please report success/failure if you try it). > > Very happy to report that this works. I'm a happy VPN camper. Glad to hear that.. thanks for the report. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mpd-netgraph as VPN client to Cisco 2500
Justin, glad this worked for you! How did you stop the Cisco box from stupidly trying to hand its own IP address to the clients over and over? I don't even get past negotiation, since the Cisco won't hand out any other addresses... (It also doesn't help that the box isn't under my direct administration, but if I could tell the support people "go look at page X in Cisco manual Y", that'd probably allow them to fix it.) Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: network buffer problem -/- natd
On Tue, Feb 19, 2002 at 07:24:09PM +0100, Marcel de Vries wrote: > After 4 hours of pinging and listening to a shoutcast stream natd rised to > his state of eating 34% proctime (top) > Connection timed out, did a restart of mpd and everything is running normal > agian. somewhat unrelated, but... why are you using both mpd and natd ? wouldn't mpd do the address translation same as ppp does ? Anyways the performance problem could be easily explained by a poor implementation of the session lookup in libalias -- e.g. resulting in heavy scanning of long lists for each received packet, or things like that. >From the (almost non-existent) comments in the libalias code it is not immediate to understand what is the underlying data structure -- maybe a hash table followed by lists -- nor if there are variables that one could monitor to see how the lookup strategy works (e.g. number of entries, average depth of the lists, etc. > > - i'm not an expert but truss, strace and grof show that most of the time > >is spent in sendto() ... This is probably related to a problem in natd which was fixed by Ruslan not long ago in current, and did not make it in RELENG_4_5 (it is in -stable though). The bug was that natd looped around a select which would always return the socket as writable, and it would keep retrying a sendto() until successful. The fix is to drop the packet when sendto fails, and rely on retransmissions instead. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: NAT
what's NAT4? On Tue, 19 Feb 2002, Juan Francisco Rodriguez Hervella wrote: > Hello, > I have been doing some perfomance tests using the standard NAT > implementation for FreeBsd, and also using NAT-PT, with the KAME > implementation. > > In throughput and delay terms, the results are much worse for NAT4. > > May that result be due to the overloading introduced by ALG in the > standard implementation? Maybe it has to analyse the packets deeper?? > > Thanks in advance. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mpd-netgraph as VPN client to Cisco 2500
Lars Eggert writes:
> How did you stop the Cisco box from stupidly trying to hand its own IP
> address to the clients over and over? I don't even get past negotiation,
> since the Cisco won't hand out any other addresses... (It also doesn't
> help that the box isn't under my direct administration, but if I could
> tell the support people "go look at page X in Cisco manual Y", that'd
> probably allow them to fix it.)
Newer versions of mpd will not even finish negotiation with a box
that uses the same IP address inside & out... this was added as a
safety check.. to disable this behavior and allow such negotiation,
apply the patch below.
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: ipcp.c
===
RCS file: /home/cvs/archie/mpd/src/ipcp.c,v
retrieving revision 1.3
retrieving revision 1.2
diff -u -r1.3 -r1.2
--- ipcp.c 2001/12/16 03:47:25 1.3
+++ ipcp.c 2001/04/12 17:03:31 1.2
@@ -19,7 +19,6 @@
#include "custom.h"
#include "msg.h"
#include "ngfunc.h"
-#include "pptp.h"
#include
#include
@@ -608,7 +607,7 @@
switch (mode) {
case MODE_REQ:
if (!IpAddrInRange(&ipcp->conf.peer_allow, *ip) || !ip->s_addr) {
-nak_ip:if (ipcp->peer_addr.s_addr == 0)
+ if (ipcp->peer_addr.s_addr == 0)
Log(LG_IPCP, (" %s", "no IP address available for peer!"));
if (Enabled(&ipcp->conf.options, IPCP_CONF_PRETENDIP)) {
Log(LG_IPCP, (" pretending that %s is OK, will ignore",
@@ -621,17 +620,6 @@
Log(LG_IPCP, (" NAKing with %s", inet_ntoa(*ip)));
FsmNak(fp, opt);
break;
- }
- if (bund->links[0]->phys->type == &gPptpPhysType) {
- struct in_addr pip;
-
- lnk = bund->links[0];
- pip = PptpGetPeerIp();
- if (ip->s_addr == pip.s_addr) {
- Log(LG_IPCP,
- (" Same as PPTP IP; would cause routing loop"));
- goto nak_ip;
- }
}
Log(LG_IPCP, (" %s is OK", inet_ntoa(*ip)));
ipcp->peer_addr = *ip;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: mpd-netgraph as VPN client to Cisco 2500
Archie, Archie Cobbs wrote: > Newer versions of mpd will not even finish negotiation with a box > that uses the same IP address inside & out... this was added as a > safety check.. to disable this behavior and allow such negotiation, > apply the patch below. you put created that patch in repsonse to my email back then about the encapsulation loop :-) (and it works great in preventing the kernel panic). The problem with the Cisco we have here is that even when it gets a NAK during negotiation (when offering its IP address to mpd), it will stupidly retry with the same address over and over, until negotiation fails. Justin doesn't seem to have this problem; in the log he posted, his Cisco box gives him a valid IP address after the NAK. That's why I'm interested in how he made it do that. If I take out the NAK patch, I believe I'll see kernel panics again; or were you saying that adding a host route can prevent this? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: mpd-netgraph as VPN client to Cisco 2500
Lars Eggert writes: > If I take out the NAK patch, I believe I'll see kernel panics again; or > were you saying that adding a host route can prevent this? Adding a host route should prevent the kernel panic. However, there was also a fix made to ng_ksocket(4) that eliminates the panic from ever happening (the offending packet is simply dropped with EDEADLK). So, the first step is one should update their kernel to prevent the panic. Once this is done, you can worry about how to actually make it work (with the host route and mpd mods). -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: network buffer problem -/- natd
Hi all, Unrelated but for everybody unknown with mpd: FYI: DESCRIPTION mpd is a user mode PPP daemon using the netgraph(4) networking system. By using Netgraph, mpd combines the robustness and flexibility of a user- mode PPP implementation with the speed and reliability of kernel-mode packet forwarding. All PPP negotiation is handled in user level code, while all data intensive operations such as encryption, compression, and multi-link framing are handled strictly in the kernel. Mpd supports sev- eral link layer types, a fully event-driven modem chat scripting lan- guage, and other features. -snip- As far as I know mpd still cannot manage IP masquerading :) I use mpd to setup a PPTP (gre encapsulation) connection between interface ep0 (public) and my Alcatel ADSL modem. Don't ask me why but it's the concept of a BIG telecom company we all love to hate in the Netherlands. KPN TELECOM. And most of the people use mpd in the Netherlands and find it a comfortable and more stable solution I think. Well I guess mxstream ADSL works fine in most cases. These other paid OS types like w9x/me, winnt, win2k/XP all can handle PPTP VPN connections only with the correct DUN version for the early win versions that is. And almost every ordinary household who owns a computer is running one of the disgusting platforms mentioned above. And I think it have to work great in combination with ADSL or else they could flush there concept down the drains. Because mxstream wants to attract and provide internet for this sector. There where a lot problems in the beginning of mxstream but they changed there design to make it more useful for a internet user. So as most of the BSD community who are in lucky circumstances to own a ADSL connection would love to use FreeBSD as a router for the rest of the network. I know more people are dealing with packet loss and losing there connection in use with mxstream ADSL. People that really use there internet extensive that is ;-) But how can we fix these problems or even look to a better alternative? Grtz, Marcel At 10:44 19-02-2002 -0800, Luigi Rizzo wrote: >On Tue, Feb 19, 2002 at 07:24:09PM +0100, Marcel de Vries wrote: > > After 4 hours of pinging and listening to a shoutcast stream natd rised to > > his state of eating 34% proctime (top) > > Connection timed out, did a restart of mpd and everything is running > normal > > agian. > >somewhat unrelated, but... why are you using both mpd and natd ? >wouldn't mpd do the address translation same as ppp does ? > >Anyways the performance problem could be easily explained by >a poor implementation of the session lookup in libalias -- e.g. >resulting in heavy scanning of long lists for each received packet, >or things like that. > > From the (almost non-existent) comments in the libalias code it is >not immediate to understand what is the underlying data structure >-- maybe a hash table followed by lists -- nor if there are variables >that one could monitor to see how the lookup strategy works (e.g. >number of entries, average depth of the lists, etc. > > > > - i'm not an expert but truss, strace and grof show that most of the time > > >is spent in sendto() ... > >This is probably related to a problem in natd which was fixed by >Ruslan not long ago in current, and did not make it in RELENG_4_5 >(it is in -stable though). > >The bug was that natd looped around a select which would always >return the socket as writable, and it would keep retrying a sendto() >until successful. >The fix is to drop the packet when sendto fails, and rely on retransmissions >instead. > > cheers > luigi > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Odd Rule in rc.firewall6
I was wondering if anyone here could explain this to me:
# Only in rare cases do you want to change these rules
#
${fw6cmd} add 100 pass all from any to any via lo0
#
# ND
#
# DAD
${fw6cmd} add pass ipv6-icmp from ff02::/16 to ::
${fw6cmd} add pass ipv6-icmp from :: to ff02::/16
I don't understand that first IPV6-ICMP rule. RFC2373 says,
2.5.2 The Unspecified Address
The address 0:0:0:0:0:0:0:0 is called the unspecified address.
...
The unspecified address must not be used as the destination address
of IPv6 packets or in IPv6 Routing Headers.
That rule sure looks like it is explicitly passing invalid
traffic. Unless someone can enlighten my ignorance here, I'm going to
nuke that rule.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Odd Rule in rc.firewall6
> On Tue, 19 Feb 2002 18:55:43 -0800
> "Crist J. Clark" <[EMAIL PROTECTED]> said:
crist.clark> I was wondering if anyone here could explain this to me:
crist.clark> # DAD
crist.clark> ${fw6cmd} add pass ipv6-icmp from ff02::/16 to ::
crist.clark> ${fw6cmd} add pass ipv6-icmp from :: to ff02::/16
crist.clark> I don't understand that first IPV6-ICMP rule. RFC2373 says,
crist.clark> 2.5.2 The Unspecified Address
crist.clark>The address 0:0:0:0:0:0:0:0 is called the unspecified address.
crist.clark>...
crist.clark>The unspecified address must not be used as the destination address
crist.clark>of IPv6 packets or in IPv6 Routing Headers.
crist.clark> That rule sure looks like it is explicitly passing invalid
crist.clark> traffic. Unless someone can enlighten my ignorance here, I'm going to
crist.clark> nuke that rule.
RFC2461 4.3. says:
Source Address
Either an address assigned to the interface from
which this message is sent or (if Duplicate Address
Detection is in progress [ADDRCONF]) the
unspecified address.
So,
${fw6cmd} add pass ipv6-icmp from :: to ff02::/16
must be retained. But, it seems
${fw6cmd} add pass ipv6-icmp from ff02::/16 to ::
is not required. When I wrote this, maybe I might confused.
But, I cannot test it just now. I'll test it tonight.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Can't see "ed0" interface when I run pppd with defaultroute option
Hi, My ed0 interface has been set up using a typical LAN style IP address of 192.168.1.100. When I run pppd (connecting to my ISP) with the defaultroute option, I can't access services on my own ed0 IP address. Eg. "telnet 192.168.1.100 25" just hangs (instead of giving me the ESMTP prompt). If I delete the default route, I can see services on my own ed0 IP address again. It is almost as if the Default route has precedence over my own ed0 interface. Can anyone help with this problem ??? Thanks, Brendan... -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
