RE: serious packet routing issue causing ntpd high load?
This endless route lookup miss message problem is reproducible without FLOWTABLE. The problem is with the multiple FIBs. I cannot reproduce this problem in my home network but the problem is easily seen at work. The route lookup miss itself in multi-FIBs configuration may be normal depending on the actual system configuration. It's the flooding of RTM_MISS messages that is abnormal. For example, if the route to the DNS servers is not configured in all FIBs, then the RTM_MISS message will be generated when an userland application sends to an explicit IP address in a specific FIB. In any case, I can reproduce the issue consistently and just trying to get a few uninterrupted hours to get it done. --Qing From: Alexander V. Chernikov [melif...@freebsd.org] Sent: Thursday, November 03, 2011 6:43 AM To: Steven Hartland Cc: Li, Qing; freebsd-stable@FreeBSD.org; li...@multiplay.co.uk Subject: Re: serious packet routing issue causing ntpd high load? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.10.2011 13:50, Steven Hartland wrote: - Original Message - From: Li, Qing qing...@bluecoat.com RTM_MISS: Lookup failed on this address: len 184, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST ::A.B.C.D I'm unable to reproduce an issue on (nearly) GENERIC 8-S, but I see nearly the same situation on 8.1-S box with FLOWTABLE enabled. Do you have FLOWTABLE option in your kernel config ? Would it be possible for you to email me what exactly does ::A.B.C.D map into WRT your system or infrastructure ? Sorry for the slow reply been out of the country. All the hosts are local machines same /24 connecting to the server for mysql. It seems to be that every packet either to or from for the mysql server is generating an RTM_MISS. And are you able to share your ifconfig -a and netstat -rn output with me privately ? On its way. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org - -- WBR, Alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ymoMACgkQwcJ4iSZ1q2meiACeKq4lhzw6scqCKzEyTNEeycxo 31QAn2q5KIRBwJpcF7yOpTe3wOcP3Aak =jfKN -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: serious packet routing issue causing ntpd high load?
Okay, I just reproduced the problem. The strange thing is the routing message appears to be endless, but if I exit route monitor and restart it, the message disappears. That indicates to me it is not the kernel that is generating the routing message continuously, but maybe it is a socket buffer issue ? Otherwise when route monitor is resumed the messages should also resume, which is not the case here. Of course why the DNS message being generated in FIB 1 triggers a RTM_MISS in FIB 2 is an issue and I am looking into it as well. --Qing -Original Message- From: Steven Hartland [mailto:kill...@multiplay.co.uk] Sent: Monday, October 10, 2011 2:51 AM To: Li, Qing; freebsd-stable@freebsd.org Cc: li...@multiplay.co.uk Subject: Re: serious packet routing issue causing ntpd high load? - Original Message - From: Li, Qing qing...@bluecoat.com RTM_MISS: Lookup failed on this address: len 184, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST ::A.B.C.D Would it be possible for you to email me what exactly does ::A.B.C.D map into WRT your system or infrastructure ? Sorry for the slow reply been out of the country. All the hosts are local machines same /24 connecting to the server for mysql. It seems to be that every packet either to or from for the mysql server is generating an RTM_MISS. And are you able to share your ifconfig -a and netstat -rn output with me privately ? On its way. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: serious packet routing issue causing ntpd high load?
Hi,
RTM_MISS: Lookup failed on this address: len 184, pid: 0, seq 0, errno
0, flags:DONE
locks: inits:
sockaddrs: DST
::A.B.C.D
Would it be possible for you to email me what exactly does ::A.B.C.D
map into WRT your system or infrastructure ?
And are you able to share your ifconfig -a and netstat -rn output
with me privately ?
--Qing
-Original Message-
From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
sta...@freebsd.org] On Behalf Of Steven Hartland
Sent: Tuesday, October 04, 2011 5:00 PM
To: freebsd-stable@freebsd.org
Cc: li...@multiplay.co.uk
Subject: serious packet routing issue causing ntpd high load?
We just updated a machine to 8-STABLE and I've noticed
that ntpd is using notible amounts of CPU 5-7% which
is very high for such a trivial daemon.
8.2-STABLE FreeBSD 8.2-STABLE #16: Tue Oct 4 09:53:17 UTC 2011
truss indicates its constantly checking and reading
from a socket
0.047297485 select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) = 1
(0x1)
0.047513160 clock_gettime(0,{1317770389.969538247 }) = 0 (0x0)
0.047604515 select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,{0.00 })
= 1 (0x1)
0.047668212 read(28,\M-8\0\^E\a\0\0\0\0@\0\0\0\^A\0...,5120) = 184
(0xb8)
0.049395293 select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) = 1
(0x1)
0.049503689 clock_gettime(0,{1317770389.971526820 }) = 0 (0x0)
0.049606219 select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,{0.00 })
= 1 (0x1)
0.049669916 read(28,\M-8\0\^E\a\0\0\0\0@\0\0\0\^A\0...,5120) = 184
(0xb8)
0.049809882 select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) = 1
(0x1)
...
running with debug enabled it sits looping outputting:-
routing message op = 7: ignored
routing message op = 7: ignored
routing message op = 7: ignored
routing message op = 7: ignored
routing message op = 7: ignored
routing message op = 7: ignored
routing message op = 7: ignored
...
It seems socket 28 is a duplicate of an internal routing socket
as seen here in the trace:-
0.044544269 socket(PF_ROUTE,SOCK_RAW,0) = 4 (0x4)
0.044595394 fcntl(4,F_DUPFD,0x14)= 28 (0x1c)
0.044645960 close(4) = 0 (0x0)
0.044695968 fcntl(28,F_SETFL,O_NONBLOCK) = 0 (0x0)
Now this looks like its RTM_MISS as defined:-
sys/net/route.h:#define RTM_MISS0x7 /* Lookup failed on
this address */
So the question was why is PF_ROUTE socket constantly
spamming RTM_MISS?
route -n monitor on this machines shows:-
got message of size 184 on Tue Oct 4 23:46:36 2011
RTM_MISS: Lookup failed on this address: len 184, pid: 0, seq 0, errno
0, flags:DONE
locks: inits:
sockaddrs: DST
::A.B.C.D
got message of size 184 on Tue Oct 4 23:46:36 2011
RTM_MISS: Lookup failed on this address: len 184, pid: 0, seq 0, errno
0, flags:DONE
locks: inits:
sockaddrs: DST
::A.B.C.D
This seems very much like the following pr which was fixed:-
Remove a bogusly introduced rtalloc_ign() in rev. 1.335/SVN 178029,
generating an RTM_MISS for every IP packet forwarded making user space
routing daemons unhappy:-
http://www.freebsd.org/cgi/query-pr.cgi?pr=124540
The box is doing no routing, its fairly basic install with
1 main IP on em0 + 1 alias + gw addres and 1 private ip on em1.
Its running mysql and thats about it.
Any ideas?
Regards
Steve
This e.mail is private and confidential between Multiplay (UK) Ltd. and
the person or entity to whom it is addressed. In the event of
misdirection, the recipient is prohibited from using, copying, printing
or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission
please telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-
unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: IPv6 / ndp taking a long time to resolve in this weeks STABLE
I haven't modified the ndp related code for quite a long time, but recently have seen some postings regarding incomplete ndp entries (still catching up on emails). Changes committed in the past year or so were related to locking and memory leak, not functional updates. I have seen this issue with ARP, where incoming ARP requests are not completing the entries until an explicit outgoing packet is generated right after the system boots. Email me when you recreate the problem. --Qing -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Pete French Sent: Wednesday, April 13, 2011 3:14 AM To: freebsd-stable@freebsd.org Subject: IPv6 / ndp taking a long time to resolve in this weeks STABLE Following on from what I write about CARP, I've noticed another strange thing happening with IPv6. Things which appear not to connect, and then connect after a few seconds. To me it looks like ndp is having a hard time mapping addresse to ether addresses. What I see is that if a ping doesnt work and I look at the ndp, it has 'no entry' in it for at least 5 seconds. Eventually it gets one, anbd thenm everyhting is fast as ever. But all a bit strange - ndp problems would epxlain what I was seeing with CARP too. Am going to try and set up a little test network here to experiment with this later today, in the meantime, has anyone else had IPv6 issues with a recent stable ? -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: upd: 7.2-8.1 many networks trouble flowtable
I am the main author of this paper you referenced in your email. The main discussion and focus of my paper was on the design and work done to separate L2 and L3 for both IPv4 and IPv6 to facilitate the elimination of GIANT lock in the networking subsystem, thus achieving high parallelism. This redesign of separately managing L2 ARP/ND6 and L3 routing tables already show performance gain on multicore systems. The flow-table enhancement is just one other component, described towards the end of the paper. Yes, It is experimental and was discussed as such in the paper as well as on the mailing list. I did not know flow-table feature was enabled by default. I wouldn't have done so myself. So help me understand you better: are you complaining about the general L2/L3 separation work, or you are angry about the flow-table enhancement in particular? cheers, -- Qing On Nov 24, 2010, at 1:54 AM, Andrey Groshev gre...@yartv.ru wrote: Hi, PPL! A couple of days ago decided to upgrade from 7.2-STABLE to 8.1-STABLE (amd64). By tradition, waited some pitfalls. But damn, not to the same degree! The hardware on the server: Motherboard: Intel SE7520JR23S CPU's: 2 x Xeon 3Ghz Ram: 4Gb Software used: openospfd, openbgpd, bind, and so on. In general, used as a boundary Router. Update ... and began: 1. The server died a few minutes after launch, not even reacting to the keyboard. By issuing a warning about em0 watchdog .. I thought to myself - broke the driver, connect the other network card. Server even stopped hanging. 2. Nearest switch does not like OSPF from the server and it shuts down a port or vlan. 3. openbgpd loads CPU nearly 100%. 4. bind does not respond, despite the fact that properly loads the CPU. In the end, I turned off everything that does not work as is necessary, Only remaining process FLOWCLEANER which can be CPU at 100%. Google started about this flowcleaner. And what happened? I found a report entitled Optimizing the BSD Routing System for Parallel Processing(1). Roughly speaking, flowtable - a new approach to routing. Dividing the levels 2 and 3 can achieve more parallelism. But in the end, due to this - to increase network performance. Ok, everything looks great! And now I ask: for whom all this? IMHO for example, ISP. Or, as stated in the above-mentioned report: The main goals for redesigning the kernel routing infrastructure was to reduce the scope of the customization necessary when deriving products from FreeBSD, and to offer a generic solution that could be an integral part of the kernel. What ultimately relevant only to the equipment is used at the ISP. Since the average user with its tiny routing table - it is not necessary. But beyond the problems begin. How long have you seen the ISP without fullview bpg? But beyond the problems begin. Almost everywhere where it is mentioned a problem with FLOWCLEANER recommended for deletion from the kernel option FLOWTABLE. And one of the co-authors wrote in his blog(2): One oversight that come up shortly afterwards is that it adversely impacts performance for systems with many routing prefixes to a greater degree than I had expected. How long have you seen the ISP without fullview bpg? It turns out that the technology is designed to increase network performance that most network generally kills, which implies that it is not suitable for use. And here it is not simply included in the source tree, and is enabled by default in the GENERIC kernel! And do not say that there was no PR - they are (3)! Sorry so long sets out the main meaning of the message is this: Why in the kernel introduced new features, if it is good only on paper? May exclude this option from the GENERIC kernel? Links: 1. - http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf 2. - http://daemonflux.blogspot.com/2010/01/updates.html 3. - http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_flowtable.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: upd: 7.2-8.1 many networks trouble flowtable
You actually haven't answered my questions. I think you are reporting multiple issues in your original email, which include issues in both userland applications as well as kernel issues (that may be related to flow-table being enabled). The paper discussed quite a few topics, in the right sequence, but if you jumped ahead or jumped around, you may make unintended assumptions. One of the main reasons for the flow-table enhancement, as its name implies, is to affinitize TCP/UDP flows to specific route/interface, even when ECMP is enabled, and the route entries in the ECMP group are changing or being shuffled constantly. This feature is specifically important when an appliance is deployed, for example, as a reverse proxy. The other benefit of the flow-table, is to reduce the L3 route table and L2 ARP/ND6 lookups by caching the search result with the connection. In earlier releases of FreeBSD there is a field called inp_route designed for this exact purpose, however, I believe it was removed back in FreeBSD 5.3 release. So to summarize, the flow-table work is necessary and important, though there may be bugs that we need to fix. Flow-table's main benefit, as it stands currrently, is mainly for L4 connections, not for L3 forwarding purposes. When we were doing performance analysis through L4 connections to measure the benefits of separating L2/L3, as noted in the paper, the performance gain was not at the expected level. Further analysis showed there were still lock contentions due to L2 table lookup. This was the other motivation for the flow-table work. I have done performance evaluation at L3 for packet forwarding tests with 100s of route entries, and I have not seen any degradation compared with 7.2. Recently we ran 8.1 on i7 processor using Avalanche testbed for performance evaluation, and noticed the locking contention is still very high in TCP connection setup and tear-down. The CPU utilization is also high due to the lock contentions, not due to flow-table feature because it was disabled. So before you conclude all of the issues that you are encountering falls within flow-table, I urge you to articulate the issues with more details. Also, once you disable flow-table through sysctl, what issues are you still running into. Yes, I personally consider the flow-table work still being experiemental. More work is being done as we speak. In addition, we are considering other enhancements for the routing code. Cheers, -- Qing From: Andrey Groshev [mailto:gre...@yartv.ru] Sent: Wed 11/24/2010 4:04 AM To: Li, Qing Cc: freebsd-stable@freebsd.org Subject: Re: upd: 7.2-8.1 many networks trouble flowtable 24.11.2010 13:18, Li, Qing ?: I am the main author of this paper you referenced in your email. Hi! I know that you also worked on this. Kip Macy mention because I found his statement regarding this issue. The main discussion and focus of my paper was on the design and work done to separate L2 and L3 for both IPv4 and IPv6 to facilitate the elimination of GIANT lock in the networking subsystem, thus achieving high parallelism. This redesign of separately managing L2 ARP/ND6 and L3 routing tables already show performance gain on multicore systems. The flow-table enhancement is just one other component, described towards the end of the paper. Yes, It is experimental and was discussed as such in the paper as well as on the mailing list. Ie You also confirms that this feature is still experimental? I did not know flow-table feature was enabled by default. I wouldn't have done so myself. Kip Macy added it to the generic kernel of head 2009-06-14 (vers. 1.526). And it so happened that when he appeared RELENG_8 she moved into the stable branch. So help me understand you better: are you complaining about the general L2/L3 separation work, or you are angry about the flow-table enhancement in particular? cheers, -- Qing I understand the importance and necessity of the features. I'll be glad when it will actually carry out what should be. But in the current situation, this feature should not be enabled by default in the generic kernel of the stable branch. Best regards, Andrey Groshev. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: upd: 7.2-8.1 many networks trouble flowtable
snip Here's an example of where disabling the flowtable solved a user's problem in October 2010: http://forums.freebsd.org/showthread.php?t=18301 snip Additionally I remember 2 or 3 posts to mailing lists here discussing how bgpd was taking up 100% CPU (or specifically an entire CPU core). I'm not sure what people did to solve that problem, but one has to wonder if flowtable was the cause and they simply didn't realise it. The context of the discussion was Andrey's original email, in which he reported multiple issues that include the em driver, routing daemons, flow-table garbage collector taking 100% CPU etc. The last issue obviously relates to the flow-table code, and I was not disputing about that. I simply asked for a clarification, which I did not receive a clear answer, on whether there are routing issues when flow-table is disabled. The reason why I asked, is because L2/L3 separation work (poorly named, of course) is more about the routing infrastructure changes in the FBSD 8.0 kernel, whereas the flow-table enhancements deal more with the connections (as detailed in my last email), and it builds on top of the L2/L3 work. snip I can't speak for the OP or his situation -- flowtable appears to work fine for me, but then again none of our RELENG_8 systems do routing nor handle large numbers of routes (very simple single-IP or multi-IP systems on two networks). See above paragraph ... I am going to change the flow-table default setting to disabled for the upcoming 8.2 release while these issues are being resolved, and the documentation is being put in place. Sounds reasonable. -- Qing ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: if_rtdel: error 47 (netgraph or mpd issue?)
I am working with Mike offline. -- Qing -Original Message- From: Mike Tancsa [mailto:m...@sentex.net] Sent: Wednesday, September 08, 2010 8:35 AM To: Vlad Galu Cc: Li, Qing; freebsd-stable@freebsd.org Subject: Re: if_rtdel: error 47 (netgraph or mpd issue?) At 11:30 AM 9/8/2010, Vlad Galu wrote: On Wed, Sep 8, 2010 at 6:12 PM, Mike Tancsa m...@sentex.net wrote: [...] FWIW, I've had a few crashes in if_rtdel() while playing with ECMP. No Netgraph on that box. Unfortunately, the stack was too corrupted to be able to see the outer frames. Hi, Actually, I dont have ECMP enabled on this box. Its basically GENERIC, minus ident router --- ident GENERIC 72,75c73,76 #options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) #options AUDIT # Security event auditing #options MAC # TrustedBSD MAC Framework #options FLOWTABLE # per-cpu routing cache --- options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache and device drivers that are unused ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: if_rtdel: error 47
Hi,
Without seeing your mpd link configuration, I am guessing the IP address
of all of
the local end points of your ppp links is the same IP address. If that's
the case,
the error message is harmless.
The reason being, for ppp links and in pre 8.0 release, if you try
pinging the local
end IP address, you will see packets are leaked out towards the default
gateway.
I fixed this issue by installing a loopback route for the local end.
Since multiple ppp links all having the same local IP address, but only
one such
loopback route is installed, when links are torn down they would try
deleting but
that entry would stay until the final link referring to that
self-pointing route
is gone.
--Qing
-Original Message-
From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
sta...@freebsd.org] On Behalf Of Mike Tancsa
Sent: Tuesday, August 31, 2010 2:02 PM
To: freebsd-stable@freebsd.org
Subject: if_rtdel: error 47
On a RELENG_8 box from aug 25th, I started seeing a constant spew of
Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47
Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed
Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3
Aug 31 00:18:29 gate8 last message repeated 2 times
Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed
Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3
Aug 31 00:18:37 gate8 last message repeated 2 times
Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed
Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3
Aug 31 00:18:38 gate8 last message repeated 2 times
What do they mean and how can I find the cause of it ? The box acts
as an LNS with about 700 ng interfaces with mpd5.5. ipv6 is enabled
on this server as well, so I am guessing it might be related to ipv6
as I havent seen it on the other LNS boxes that have the same setup,
except no ipv6. It was happily running for a few days until this
error started showing up ?
The error seems to be in sys/if.c
if_rtdel(struct radix_node *rn, void *arg)
{
struct rtentry *rt = (struct rtentry *)rn;
struct ifnet*ifp = arg;
int err;
if (rt-rt_ifp == ifp) {
/*
* Protect (sorta) against walktree recursion
problems
* with cloned routes
*/
if ((rt-rt_flags RTF_UP) == 0)
return (0);
err = rtrequest_fib(RTM_DELETE, rt_key(rt), rt-
rt_gateway,
rt_mask(rt), rt-
rt_flags|RTF_RNH_LOCKED,
(struct rtentry **) NULL, rt-
rt_fibnum);
if (err) {
log(LOG_WARNING, if_rtdel: error %d\n,
err);
}
}
return (0);
}
---Mike
Mike Tancsa, tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-
unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: if_rtdel: error 47
Hi, Thanks for looking! Yes, they are the same. However, I dont see this error on the other box which does not have ipv6 negotiation on the line (set bundle enable ipv6cp). Only since enabling ipv6 negotiation and oddly enough only after a few days did the error start happening. I went through the change history and noticed I made the following changelist for IPv4, http://svn.freebsd.org/viewvc/base/head/sys/netinet/in.c?r1=201811r2=20 3401 Maybe related and something similar needs to be done for IPv6 ... The other issue I noticed was that the link local ipv6 stopped working on a test machine. eg pinging the multicast address on the local link stopped working for some reason ie ping ff02::1%ng155 stopped working on a machine I was testing just the day before. Killing the l2tp session and having it reconnect fixed the issue. Nothing obvious comes to mind at the moment. OK, another issue I am seeing. The routing table seems to have junk in it. eg That explains the errno = 47, EAFNOSUPPORT. I also noticed in your routing table output that all of entries that have junk are related to the ng interface. -- Qing ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: patch: bad ipv6 neighbor solicitation
Thanks for reporting back. I asked you for a routing table dump in my previous email, would you mind emailing it to me privately? -- Qing -Original Message- From: Tom Pusateri [mailto:pusat...@bangj.com] Sent: Tuesday, December 15, 2009 1:28 PM To: Li, Qing Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation I didn't think this routing patch was related to the bad neighbor solicitation messages as suggested in the subject field but I tried it anyway. It does not fix my IPv6 problem. I still get bad neighbor solicitation messages and freebsd 8 doesn't respond to 4/5 IPv6 pings. Thanks, Tom On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 = default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with route add *your parameters* or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same
RE: patch: bad ipv6 neighbor solicitation
Thanks for sending me the routing table output. Actually I believe both your problems are indeed related to the prefix route. I was able to reproduce Dennis Glatting's problem, which was due to one of the prefix entry being off-link. In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad disappeared and is not in the routing table. If you add the route by hand the problem should go away. I guess the question is what triggered the prefix route deletion. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Li, Qing Sent: Tuesday, December 15, 2009 1:46 PM To: Tom Pusateri Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org Subject: RE: patch: bad ipv6 neighbor solicitation Thanks for reporting back. I asked you for a routing table dump in my previous email, would you mind emailing it to me privately? -- Qing -Original Message- From: Tom Pusateri [mailto:pusat...@bangj.com] Sent: Tuesday, December 15, 2009 1:28 PM To: Li, Qing Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation I didn't think this routing patch was related to the bad neighbor solicitation messages as suggested in the subject field but I tried it anyway. It does not fix my IPv6 problem. I still get bad neighbor solicitation messages and freebsd 8 doesn't respond to 4/5 IPv6 pings. Thanks, Tom On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 = default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64
net/mpd5, ppp, proxy-arp issues
Hi, Recently there have been several reports regarding issues with ppp, mpd5 and proxy-arp configuration over the ppp links. I read through the various postings and the problems seem to be: 1. Unable to add proxy-arp entries for the remote ppp clients. 2. Log showing ifa_add_loopback_route: insertion failed causing some userland applications to fail. May I ask that you try applying patch http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff and report back if the patch fixes your problems. And if not, please describe what additional issues you are having. Thanks, -- Qing ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: IPv6 - bad neighbor solicitation messages
Please email me your routing table privately, but I am suspecting the following temporary patch would fix your issue. Please give it a try and report back. http://people.freebsd.org/~qingli/nd6-ns.diff -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Tom Pusateri Sent: Thursday, December 10, 2009 7:16 PM To: freebsd-stable@freebsd.org Subject: IPv6 - bad neighbor solicitation messages I'm having intermittent IPv6 issues on one FreeBSD 8-stable box. I've tried to ping6 the FreeBSD-8 stable (crag) (as of 12/9/09) from snow leopard (glow) and from a freebsd 7.2 box (gw). I've tried replacing the fxp0 interface in the FreeBSD-8 stable box with an em0 interface and it works with the FreeBSD 7.2 box but the same problem from the Snow Leopard box. The bad neighbor solicitation messages keep increasing with the IPv6 pings. Any other thing I can collect to troubleshoot? Thanks, Tom glow pusateri$ ping6 crag PING6(56=40+8+8 bytes) 2610:28:1800:4001:225:ff:fef1:7305 -- 2610:28:1800:4001:20e:cff:fe9f:faad Request timeout for icmp_seq=0 Request timeout for icmp_seq=1 Request timeout for icmp_seq=2 Request timeout for icmp_seq=3 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=4 hlim=63 time=0.784 ms Request timeout for icmp_seq=5 Request timeout for icmp_seq=6 Request timeout for icmp_seq=7 Request timeout for icmp_seq=8 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=9 hlim=63 time=0.633 ms Request timeout for icmp_seq=10 Request timeout for icmp_seq=11 Request timeout for icmp_seq=12 Request timeout for icmp_seq=13 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=14 hlim=63 time=0.654 ms Request timeout for icmp_seq=15 ^C --- crag.foo.com ping6 statistics --- 17 packets transmitted, 3 packets received, 82.4% packet loss round-trip min/avg/max/std-dev = 0.633/0.690/0.784/0.067 ms tcp: 153 packets sent 146 data packets (31776 bytes) 3 data packets (240 bytes) retransmitted 1 data packet unnecessarily retransmitted 0 resends initiated by MTU discovery 4 ack-only packets (2 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 196 packets received 137 acks (for 31777 bytes) 6 duplicate acks 0 acks for unsent data 52 packets (4277 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 1 connection established (including accepts) 4 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 137 segments updated rtt (of 73 attempts) 2 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 50 correct data packet header predictions 1 syncache entry added 0 retransmitted 1 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 1 SACK recovery episode 1 segment rexmit in SACK recovery episodes 48 byte rexmits in SACK recovery episodes 7 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the
patch: bad ipv6 neighbor solicitation
Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 = default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with route add *your parameters* or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table I did delete the lo0 route before I exected the above command. Also, I haven't been able to specify a higher metric (e.g., -metric 2). That is rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route
RE: proxy arp and MPD in RELENG_8
The patch is now available at http://people.freebsd.org/~qingli/PPP-Patch-2.diff You need to rebuild the kernel as well as the userland arp utility. I have performed various but limited unit testing, including simulating the reported PPP issue. The patch appears to be doing what it supports to. Please give it a try and report back. Thanks, -- Qing -Original Message- From: Li, Qing Sent: Thursday, December 10, 2009 10:31 PM To: Li, Qing; Mario Pavlov; freebsd-stable@freebsd.org; freebsd- curr...@freebsd.org Subject: RE: proxy arp and MPD in RELENG_8 Hi, I think I managed to reproduce this issue. The root cause appears to be the SIN_PROXY usage, which is no longer part of any routing entry after the L2/L3 rewrite. As such, the RTM_GET command should be issued once in the ARP utility, not twice. In addition, since ARP does not apply to PPP link type, the prefix route of the local end point needs to be returned in order for the subsequent RTM_ADD command to succeed. I need to update the routing code a bit more to properly handle such proxy-arp scenario. In the meantime, please try a hack at http://people.freebsd.org/~qingli/ppp-patch.diff and let me know how it works out for you. The hack appears to work in my test environment. I need just a bit more time to work out the permanent solution in the kernel routing code, as well as the utilities in the userland. -- Qing -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Li, Qing Sent: Wednesday, December 09, 2009 12:04 PM To: Mario Pavlov; freebsd-stable@freebsd.org; freebsd- curr...@freebsd.org Subject: RE: proxy arp and MPD in RELENG_8 Let me look into this issue and work with you offline. I have been quite busy with day job and just starting to slowly resume my FreeBSD work. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org on behalf of Mario Pavlov Sent: Wed 12/9/2009 11:01 AM To: freebsd-stable@freebsd.org; freebsd-curr...@freebsd.org Subject: proxy arp and MPD in RELENG_8 Hi, some time ago I noticed that there's a problem with the new arp implementation - proxy arp was somehow not working when mpd is involved. I decided to try this out again assuming it was fixed for the release...unfortunately the problem is still there... Here are the last few lines of the mpd output: [B-1] IPCP: state change Ack-Rcvd -- Opened [B-1] IPCP: LayerUp [B-1] 192.168.10.1 - 192.168.10.50 [B-1] IFACE: Connecting tcpmssfix [B-1] IFACE: Add address 192.168.10.1/32-192.168.10.50 to ng0 [B-1] exec: /usr/sbin/arp -S 192.168.10.50 0:e0:28:62:e:9 pub [B-1] system: command /usr/sbin/arp returned 256 [B-1] IFACE: Up event [B-1] IFACE: idle-timeout: 1800 seconds [B-1] IFACE: Change interface flags: -0 +1 there this is mpd.conf: startup: default: load pptp_server pptp_server: set ippool add pool1 192.168.10.50 192.168.10.99 create bundle template B set iface enable proxy-arp log +iface2 set iface idle 1800 set iface enable tcpmssfix set ipcp yes vjcomp set ipcp ranges 192.168.10.1/32 ippool pool1 set ipcp dns 192.168.10.1 set bundle enable compression set ccp yes mppc set mppc yes e40 set mppc yes e128 set mppc yes stateless create link template L pptp set link action bundle B set link enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set link mtu 1460 set pptp self pub.ip.add.res set link enable incoming this is probably the most common VPN setup and it was working fine with 7.2-STABLE but after I upgraded to 8-STABLE it broke up... Is there a workaround or a plan to fix this? Or should I just go back to RELENG_7? thank you. P.S. this is discussed in the forums as well: http://forums.freebsd.org/showthread.php?t=8427 - ? ?? ?? iZone.bg ? ??? ?? 5?? ??? Acer! http://www.izone.bg/6/index.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- unsubscr...@freebsd.org ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman
RE: IPv6 - bad neighbor solicitation messages
I haven't made any significant changes in the IPv6 code for 3 months now. Could you please get a packet capture and email it to me? Thanks, -- Qing From: owner-freebsd-sta...@freebsd.org on behalf of Tom Pusateri Sent: Thu 12/10/2009 7:15 PM To: freebsd-stable@freebsd.org Subject: IPv6 - bad neighbor solicitation messages I'm having intermittent IPv6 issues on one FreeBSD 8-stable box. I've tried to ping6 the FreeBSD-8 stable (crag) (as of 12/9/09) from snow leopard (glow) and from a freebsd 7.2 box (gw). I've tried replacing the fxp0 interface in the FreeBSD-8 stable box with an em0 interface and it works with the FreeBSD 7.2 box but the same problem from the Snow Leopard box. The bad neighbor solicitation messages keep increasing with the IPv6 pings. Any other thing I can collect to troubleshoot? Thanks, Tom glow pusateri$ ping6 crag PING6(56=40+8+8 bytes) 2610:28:1800:4001:225:ff:fef1:7305 -- 2610:28:1800:4001:20e:cff:fe9f:faad Request timeout for icmp_seq=0 Request timeout for icmp_seq=1 Request timeout for icmp_seq=2 Request timeout for icmp_seq=3 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=4 hlim=63 time=0.784 ms Request timeout for icmp_seq=5 Request timeout for icmp_seq=6 Request timeout for icmp_seq=7 Request timeout for icmp_seq=8 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=9 hlim=63 time=0.633 ms Request timeout for icmp_seq=10 Request timeout for icmp_seq=11 Request timeout for icmp_seq=12 Request timeout for icmp_seq=13 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=14 hlim=63 time=0.654 ms Request timeout for icmp_seq=15 ^C --- crag.foo.com ping6 statistics --- 17 packets transmitted, 3 packets received, 82.4% packet loss round-trip min/avg/max/std-dev = 0.633/0.690/0.784/0.067 ms tcp: 153 packets sent 146 data packets (31776 bytes) 3 data packets (240 bytes) retransmitted 1 data packet unnecessarily retransmitted 0 resends initiated by MTU discovery 4 ack-only packets (2 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 196 packets received 137 acks (for 31777 bytes) 6 duplicate acks 0 acks for unsent data 52 packets (4277 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 1 connection established (including accepts) 4 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 137 segments updated rtt (of 73 attempts) 2 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 50 correct data packet header predictions 1 syncache entry added 0 retransmitted 1 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 1 SACK recovery episode 1 segment rexmit in SACK recovery episodes 48 byte rexmits in SACK recovery episodes 7 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 169 datagrams received 0 with incomplete header
RE: proxy arp and MPD in RELENG_8
Hi, I think I managed to reproduce this issue. The root cause appears to be the SIN_PROXY usage, which is no longer part of any routing entry after the L2/L3 rewrite. As such, the RTM_GET command should be issued once in the ARP utility, not twice. In addition, since ARP does not apply to PPP link type, the prefix route of the local end point needs to be returned in order for the subsequent RTM_ADD command to succeed. I need to update the routing code a bit more to properly handle such proxy-arp scenario. In the meantime, please try a hack at http://people.freebsd.org/~qingli/ppp-patch.diff and let me know how it works out for you. The hack appears to work in my test environment. I need just a bit more time to work out the permanent solution in the kernel routing code, as well as the utilities in the userland. -- Qing -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Li, Qing Sent: Wednesday, December 09, 2009 12:04 PM To: Mario Pavlov; freebsd-stable@freebsd.org; freebsd- curr...@freebsd.org Subject: RE: proxy arp and MPD in RELENG_8 Let me look into this issue and work with you offline. I have been quite busy with day job and just starting to slowly resume my FreeBSD work. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org on behalf of Mario Pavlov Sent: Wed 12/9/2009 11:01 AM To: freebsd-stable@freebsd.org; freebsd-curr...@freebsd.org Subject: proxy arp and MPD in RELENG_8 Hi, some time ago I noticed that there's a problem with the new arp implementation - proxy arp was somehow not working when mpd is involved. I decided to try this out again assuming it was fixed for the release...unfortunately the problem is still there... Here are the last few lines of the mpd output: [B-1] IPCP: state change Ack-Rcvd -- Opened [B-1] IPCP: LayerUp [B-1] 192.168.10.1 - 192.168.10.50 [B-1] IFACE: Connecting tcpmssfix [B-1] IFACE: Add address 192.168.10.1/32-192.168.10.50 to ng0 [B-1] exec: /usr/sbin/arp -S 192.168.10.50 0:e0:28:62:e:9 pub [B-1] system: command /usr/sbin/arp returned 256 [B-1] IFACE: Up event [B-1] IFACE: idle-timeout: 1800 seconds [B-1] IFACE: Change interface flags: -0 +1 there this is mpd.conf: startup: default: load pptp_server pptp_server: set ippool add pool1 192.168.10.50 192.168.10.99 create bundle template B set iface enable proxy-arp log +iface2 set iface idle 1800 set iface enable tcpmssfix set ipcp yes vjcomp set ipcp ranges 192.168.10.1/32 ippool pool1 set ipcp dns 192.168.10.1 set bundle enable compression set ccp yes mppc set mppc yes e40 set mppc yes e128 set mppc yes stateless create link template L pptp set link action bundle B set link enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set link mtu 1460 set pptp self pub.ip.add.res set link enable incoming this is probably the most common VPN setup and it was working fine with 7.2-STABLE but after I upgraded to 8-STABLE it broke up... Is there a workaround or a plan to fix this? Or should I just go back to RELENG_7? thank you. P.S. this is discussed in the forums as well: http://forums.freebsd.org/showthread.php?t=8427 - ? ?? ?? iZone.bg ? ??? ?? 5?? ??? Acer! http://www.izone.bg/6/index.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- unsubscr...@freebsd.org ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: proxy arp and MPD in RELENG_8
Let me look into this issue and work with you offline. I have been quite busy with day job and just starting to slowly resume my FreeBSD work. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org on behalf of Mario Pavlov Sent: Wed 12/9/2009 11:01 AM To: freebsd-stable@freebsd.org; freebsd-curr...@freebsd.org Subject: proxy arp and MPD in RELENG_8 Hi, some time ago I noticed that there's a problem with the new arp implementation - proxy arp was somehow not working when mpd is involved. I decided to try this out again assuming it was fixed for the release...unfortunately the problem is still there... Here are the last few lines of the mpd output: [B-1] IPCP: state change Ack-Rcvd -- Opened [B-1] IPCP: LayerUp [B-1] 192.168.10.1 - 192.168.10.50 [B-1] IFACE: Connecting tcpmssfix [B-1] IFACE: Add address 192.168.10.1/32-192.168.10.50 to ng0 [B-1] exec: /usr/sbin/arp -S 192.168.10.50 0:e0:28:62:e:9 pub [B-1] system: command /usr/sbin/arp returned 256 [B-1] IFACE: Up event [B-1] IFACE: idle-timeout: 1800 seconds [B-1] IFACE: Change interface flags: -0 +1 there this is mpd.conf: startup: default: load pptp_server pptp_server: set ippool add pool1 192.168.10.50 192.168.10.99 create bundle template B set iface enable proxy-arp log +iface2 set iface idle 1800 set iface enable tcpmssfix set ipcp yes vjcomp set ipcp ranges 192.168.10.1/32 ippool pool1 set ipcp dns 192.168.10.1 set bundle enable compression set ccp yes mppc set mppc yes e40 set mppc yes e128 set mppc yes stateless create link template L pptp set link action bundle B set link enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set link mtu 1460 set pptp self pub.ip.add.res set link enable incoming this is probably the most common VPN setup and it was working fine with 7.2-STABLE but after I upgraded to 8-STABLE it broke up... Is there a workaround or a plan to fix this? Or should I just go back to RELENG_7? thank you. P.S. this is discussed in the forums as well: http://forums.freebsd.org/showthread.php?t=8427 - ? ?? ?? iZone.bg ? ??? ?? 5?? ??? Acer! http://www.izone.bg/6/index.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: NFS issues on 8.0-BETA4
Hi Doug, Simply adding -o udp to my mount command made the NFS mount work correctly. Qing, would it be beneficial to attempt the patch in light of these findings? Have you tried the patch that I sent you privately? Does it work for you? Thanks, -- Qing ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: NFS issues on 8.0-BETA4
I cannot sucessfully mount exports from the NFSv3 server on the 8.0-BETA4 client. All works well with 7.2 clients. The strange thing is, the directory in which I mount the nfs filesystem disappears, and I get an error when I attempt to access the directory. This may be a known issue that a couple of us have been working on yesterday. Would you be willing to try out a temporary patch? -- Qing ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: 8.0-BETA3/IPv6: route: bad keyword: cloning
Upon booting an 8.0-BETA3 system with IPv6 enabled, I saw this in the console boot output: route: bad keyword: cloning usage: route [-dnqtv] command [[modifiers] args] This looks like it's from line 1062/1063 of /etc/network.subr v1.195.2.4. This system is not an IPv6 router, so do I particularly need $ipv6_default_interface set in rc.conf? Is there a situation where -cloning (still referenced in the man page) is a valid option to route (in inet6 context at least)? If no, should I file a PR? (I searched GNATS but didn't find anything matching this.) Route cloning is obsolete. Please report issues concerning 8.0 to freebsd-curr...@freebsd.org. Thanks, -- Qing ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: 8.0-BETA3/IPv6: route: bad keyword: cloning
Regarding the man page issue, after a quick investigation, and to make a long story short, Kip Macy and I spent a bunch of time testing and fixing a few last minute bugs before my big commit last December. Kip actually took care of this man page and one other issue in ndp command. Somehow these two last minute changes fell through the cracks and did not make it into r186119. Kip will fix it again. Thank you for catching the bug. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Li, Qing Sent: Friday, September 04, 2009 11:15 AM To: Jeff Blank; freebsd-stable@freebsd.org Cc: FreeBSD Current Subject: RE: 8.0-BETA3/IPv6: route: bad keyword: cloning Upon booting an 8.0-BETA3 system with IPv6 enabled, I saw this in the console boot output: route: bad keyword: cloning usage: route [-dnqtv] command [[modifiers] args] This looks like it's from line 1062/1063 of /etc/network.subr v1.195.2.4. This system is not an IPv6 router, so do I particularly need $ipv6_default_interface set in rc.conf? Is there a situation where -cloning (still referenced in the man page) is a valid option to route (in inet6 context at least)? If no, should I file a PR? (I searched GNATS but didn't find anything matching this.) Route cloning is obsolete. Please report issues concerning 8.0 to freebsd-curr...@freebsd.org. Thanks, -- Qing ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
Just another case where the route must be created: That's probably because I explicitly disabled such route installation for PPP link type. Please apply patch http://people.freebsd.org/~qingli/patch and let me know if that solves your problem. Thanks, -- Qing [r...@avoriaz ~]# ifconfig gif0 gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280 tunnel inet 212.239.166.57 -- 94.23.44.41 inet6 fe80::21d:60ff:fead:2ace%gif0 prefixlen 64 scopeid 0x4 inet6 2001:41d0:2:2d29:1::: -- 2001:41d0:2:2d29:0::: prefixlen 128 options=1ACCEPT_REV_ETHIP_VER [r...@avoriaz ~]# ping6 2001:41d0:2:2d29:1::: PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1::: -- 2001:41d0:2:2d29:1::: ^C --- 2001:41d0:2:2d29:1::: ping6 statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss [r...@avoriaz ~]# route add -inet6 2001:41d0:2:2d29:1::: -interface lo0 add host 2001:41d0:2:2d29:1:::: gateway lo0 [r...@avoriaz ~]# ping6 2001:41d0:2:2d29:1::: PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1::: -- 2001:41d0:2:2d29:1::: 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.531 ms 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.884 ms 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.748 ms ^C --- 2001:41d0:2:2d29:1::: ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.531/0.721/0.884/0.145 ms Thanks Henri -Original Message- From: Henri Hennebert [mailto:h...@restart.be] Sent: Sat 7/11/2009 3:09 AM To: Li, Qing Cc: freebsd-stable@freebsd.org; freebsd-...@freebsd.org Subject: Re: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Li, Qing wrote: Hi, Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/ and let me know how it works out for you. I thought I had committed the patch but turned out I didn't. I apply the patch, reset my pf.conf to its previous content and all is running smoothly. By the way, I discover after my post that my solution was not working for long (many bytes) connections and this is solved too. Many thank for your time Henri PS please commit as soon as possible On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: This is by design as part of the new architecture in 8.0, which maintains the L2 ARP/ND6 and L3 routing tables separately. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org on behalf of Henri Hennebert Sent: Fri 7/10/2009 5:32 AM To: freebsd-stable@freebsd.org; freebsd...@freebsd.org Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [r...@avoriaz ~]# ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO 4 ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX half-duplex) status: active [r...@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if=em0 block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [r...@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet quit Connection closed. [r...@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... ---Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if
RE: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
The patch has been committed, svn revision 195643. Thanks, -- Qing -Original Message- From: Henri Hennebert [mailto:h...@restart.be] Sent: Sat 7/11/2009 3:09 AM To: Li, Qing Cc: freebsd-stable@freebsd.org; freebsd-...@freebsd.org Subject: Re: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Li, Qing wrote: Hi, Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/ and let me know how it works out for you. I thought I had committed the patch but turned out I didn't. I apply the patch, reset my pf.conf to its previous content and all is running smoothly. By the way, I discover after my post that my solution was not working for long (many bytes) connections and this is solved too. Many thank for your time Henri PS please commit as soon as possible On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: This is by design as part of the new architecture in 8.0, which maintains the L2 ARP/ND6 and L3 routing tables separately. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org on behalf of Henri Hennebert Sent: Fri 7/10/2009 5:32 AM To: freebsd-stable@freebsd.org; freebsd...@freebsd.org Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [r...@avoriaz ~]# ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX half-duplex) status: active [r...@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if=em0 block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [r...@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet quit Connection closed. [r...@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... ---Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.100:1d:60:ad:2a:ce 2001:41d0:2:2d29:1:1::00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
Hi, Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/ and let me know how it works out for you. I thought I had committed the patch but turned out I didn't. On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: This is by design as part of the new architecture in 8.0, which maintains the L2 ARP/ND6 and L3 routing tables separately. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org on behalf of Henri Hennebert Sent: Fri 7/10/2009 5:32 AM To: freebsd-stable@freebsd.org; freebsd...@freebsd.org Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [r...@avoriaz ~]# ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX half-duplex) status: active [r...@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if=em0 block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [r...@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet quit Connection closed. [r...@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... ---Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.100:1d:60:ad:2a:ce 2001:41d0:2:2d29:1:1::00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
