Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic
The following reply was made to PR kern/153938; it has been noted by GNATS. From: PseudoCylon To: Juergen Lock Cc: bug-follo...@freebsd.org, n...@jelal.kn-bremen.de Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic Date: Sun, 16 Jan 2011 22:24:07 -0800 (PST) - Original Message > From: Juergen Lock > To: PseudoCylon > Cc: bug-follo...@freebsd.org; n...@jelal.kn-bremen.de > Sent: Fri, January 14, 2011 10:36:50 AM > Subject: Re: kern/153938: [run] [panic] [patch] Workaround for > use-after-free >panic > > On Thu, Jan 13, 2011 at 04:47:21PM -0800, PseudoCylon wrote: > > Hello, > Hi! > > > > Thank you for the patch. > > > You're welcome! :) > > > I have applied it. Please try patched driver out. > > http://gitorious.org/run/run/trees/ratectl_fix/dev/usb/wlan > > > > I added locks to your patch, so saved pointers are more reliable. > > I see you removed the rn->wcid code, I guess I should have > explained what it's for: ni->ni_associd already gets zeroed before > run_node_cleanup() is called so with your version no sc->sc_ni[wcid] > ever gets set to NULL. > You're right. > +if (wcid == 0) > +wcid = rn->wcid; Is there any reason to test "ni->ni_associd == 0"? We know it is 0. AK ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: capturing packet from wlan0 with netgraph?
Hi,
Please file a PR about this and the output of "show registers".
I bet that the ip pointer isn't aligned at that point in the code.
Whatever is passing the packet to the IP layer should be re-aligning
things beforehand.
(eg, look at what the ethernet ipfw hook code does - if the ether type
is ipv4/ipv6, it actually realigns the packets before passing it back
up the stack.)
Adrian
On 13 January 2011 16:25, Monthadar Al Jaberi wrote:
> sorry but I have not worked with this for a while now, After some
> thoughts I dont think using netgraph will do me any good, because
> traffic can still flow through the antennas of the cards.
>
> If you think it would still be useful to see more ddb prompt for other
> scenarios I am happy to try and supply that, but I won't have some
> free time until late tomorrow :)
>
> thnx again!
>
> On Thu, Jan 13, 2011 at 7:53 AM, Adrian Chadd wrote:
>> I've encountered this before.
>>
>> The mbuf's there aren't always aligned at this point.
>>
>>
>>
>> Adrian
>>
>> On 13 January 2011 14:17, Jayachandran C. wrote:
>>> On Thu, Jan 13, 2011 at 11:08 AM, Adrian Chadd wrote:
Find out what the address is that's causing the problem. There's
plenty of places where unaligned mbuf's exist in the IP code and
aren't correctly realigned before being touched.
MIPS people - is "address error" an alignment problem?
>>>
>>> Address error can be an alignment problem (or some other cases like
>>> accessing kernel address from userspace).
>>>
>>> But looking at the crash, it certainly seems like in ip_input, the line
>>> 435 if (ip->ip_v != IPVERSION) {
>>>
>>> got a bad address for the ip pointer.
>>>
>>> The output of 'show registers' at the ddb prompt would be useful to
>>> debug further.
>>>
>>>
On 30 December 2010 21:47, Monthadar Al Jaberi wrote:
> Hi,
>
> I have an idea in my head and would like to know if it is possible.
>
> I want to simulate and test the net80211 mesh code in FreeBSD Current.
> I have an RSPRO board with 3 atheros cards.
>
> My basic idea is to run three jails each having its own network
> stack, and redirect all data packets coming out/in of the wlan driver
> to a Server running a home brew application that simulates the medium.
> That would be great, right? Realtime unchanged code to test, running
> different application in their own jails.
>
> So first I started to test netgraph with a simple test case, I want to
> receive all packets from one wireless card and see the data in
> wireshark or tcpdump...
>
> This is my netgraph code:
> mkpeer wlan0: hub lower hook0
> name wlan0:lower hub
> connect hub: wlan0: hook1 upper
> connect hub: arge0: hook2 lower
>
>
> So if I understood man ng_ether correct, this should capture
> everything from wlan and redirect to ethernet cable.
>
> But I get a panic after a couple of seconds:
> Trap cause = 4 (address error (load or I-fetch) - kernel mode)
> [ thread pid 11 tid 100037 ]
> Stopped at ip_input+0xd8: lw v0,0(s0)
>
> I suspect that data flows to all hooks of the hub, and that is a bad
> thing right? Need to create a special hub node to filter data? Or
> maybe use two ethernet cables for out resp. in?
>
> Is it even possible to do what I want? Or am I thinking wrong? And is
> there a simpler way?
>
> What I want is to test mesh code in a bunch of FreeBSD systems without
> moving the hardware, one could just stack RSPROs and connected them a
> big switch and a PC.
> Hope was I clear in my thoughts.
>
> Best regards,
> --
> //Monthadar Al Jaberi
>>>
>>> JC.
>>>
>>
>
>
>
> --
> //Monthadar Al Jaberi
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: TCP resident expert?
[trimming freebsd-current@ and moving to more canonical freebsd-net@] On 01/16/11 23:15, Robert Watson wrote: > > On Sat, 15 Jan 2011, William Allen Simpson wrote: > >> Who's the kernel expert on TCP around here? ISC wants me to port >> TCPCT to FreeBSD. Although I've joined this list (some time ago), >> I've not seen any traffic discussing TCP'ish things. Need somebody >> willing to walk me through the processes and check my code. > > I don't think there's any single "the" expert -- rather, work on TCP is > distributed over a number of developers who take various interests in > the topic. At the risk of pointing fingers: > > Lawrence Stewart has recently been involved in pluggable > congestion control, new congestion control algorithms, TCP tracing, and > various other things, and has been among our most active hands in TCP > for the last year especially. He might be the best first port of call > because of this recent activity. I've been loosely following Bill's work on TCPCT since early last year and although I have an interest in it, I've had no spare cycles to contribute anything concrete to the discussion, specification or implementation effort. I'd be happy to eyeball patches but it would be good to get others involved as well if possible - I'm stretched too thin to be reliably useful at the moment and for the foreseeable future. Andre would definitely be a good reviewer for this work. Others of course welcome. Cheers, Lawrence ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bogus 0 len IP packet, was: Hang in VOP_LOCK1_APV on 8-STABLE with NFS.
On Sun, Jan 16, 2011 at 08:54:59AM -0500, Rick Macklem wrote: > Ronald has reported having a problem with the FreeBSD NFS client using > 8.2-prerelease. I've redirected it here, since it looks like there is > a TCP/IP issue that is causing it. > > > > > >> > > >> These are the links to the dumps: > > >> http://klop.ws/~ronald/nfs-problem/procstat.nolockd > > >> http://klop.ws/~ronald/nfs-problem/ps.nolockd > > >> http://klop.ws/~ronald/nfs-problem/linux5.nfs.nolockd.dump.gz > > >> http://klop.ws/~ronald/nfs-problem/linux5.nfs.with_rpc_patch.dump.gz > > >> > > I looked at the last of these via wireshark and it seems that the FreeBSD > client is sending bogus TCP/IP packets with a IP length == 0. (If you look > at the above dump (...with_rpc_patch.dump.gz), the first one is at packet #46, > then #3024, then persistently starting at #3234.) Basically the packet looks > like: > frame len: 4446 > MAC: dst 00:0d:56:70:b7:6c src b8:ac:6f:47:73:6e type: 08 00 (IP) > IP > version: 4 > header length: 20 > differentiated services field: 0x00 > total length: 0 > - followed by what looks like a legitimate TCP/IP packet > > Here's the first bytes of the raw packet data: > 00 0d 56 70 b7 6c b8 ac 6f 47 73 6e 08 00 > 45 00 00 00 ... > > After this packet is sent to the Linux server, it replies with a TCP ack, > which gets ACK'd from FreeBSD as well. For the persistent case, it just > keeps doing this (bogus 0 length packet from FreeBSD -> Linux server, > followed by the two TCP ack packets) over and over and over again, to > the end of the dump. > > So, does anyone have an idea why the IP length field would be set to 0 > for these TCP/IP packets? > > Here's some info from Ronald w.r.t. his hardware. (All I can think of is > that he could try disabling TSO, etc?) > > Thanks in advance for any help with this, rick > It seems that issue came from TSO. Driver will set ip_len and ip_sum field to 0 before passing the TCP segment to controller. The failed length were 4446, 5858, 3034 and 4310 and the total number of such frames are more than 35k within 90 seconds. Since failed length 4310 is continuously repeated I guess there is edge case where em(4) didn't free failed TCP segment for TSO. I remember there was commit to HEAD(r217295) which could be related with this issue. > > > > I just looked at the last dump and there seems to be a network > > > issue. > > > (It first shows up at packet #46, then again at #3025, then > > > persistently > > > starting at #3234.) > > > > > > I'd like to post on freebsd-net@ to see if anyone more conversant > > > with > > > TCP/IP can look, but first I'd like to get a little more info on > > > your > > > hardware/software config. > > > > > > In particular, what network hardware does the FreeBSD client use? > > > > > > And I assume the server is some variant of Linux? > > > > > > Thanks for creating the tcpdumps, rick > > > ps: If you look on wireshark, the problem seems to start with a > > > badly formed IP datagram that then causes acks in both > > > directions. > > > > We are getting off list now. I don't know how good that is. > > > I've redirected it to freebsd-net@ in the hopes that networking folks > can help. > > > But here is some info. I also noticed the bad packets. And my computer > > is > > resending the same info at quite a high rate (MB/s). > > The server is an up-to-date Linux Debian 5 with a 2.6.26-1-686-bigmem > > kernel. Colleagues using Linux clients don't have these problems. > > > > dmesg | grep em0 > > em0: port 0xece0-0xecff > > mem > > 0xf7fe-0xf7ff,0xf7fd9000-0xf7fd9fff irq 21 at device 25.0 on > > pci0 > > em0: Using an MSI interrupt > > em0: [FILTER] > > em0: Ethernet address: b8:ac:6f:47:73:6e > > > > pciconf -lv > > em0@pci0:0:25:0: class=0x02 card=0x02761028 chip=0x10de8086 > > rev=0x02 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel Gigabit network connection (82567LM-3 )' > > class = network > > subclass = ethernet > > > > > > [root@ronald ~]# ifconfig em0 > > em0: flags=8843 metric 0 mtu > > 1500 > > options=219b > > ether b8:ac:6f:47:73:6e > > inet 10.1.20.49 netmask 0xff00 broadcast 10.1.20.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > Thanks for looking into this. If you need more just let me know. I can > > also reproduce the problem and send nfsstat or netstat output or > > > > Thanks, > > Ronald. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW
On Sun, Jan 16, 2011 at 05:55:06PM +, Bjoern A. Zeeb wrote:
> On Sun, 16 Jan 2011, Marius Strobl wrote:
>
> Hi,
>
> >On Fri, Jan 14, 2011 at 01:41:09PM +0300, Lev Serebryakov wrote:
> >>Hello, Marius.
> >>You wrote 14 ?? 2011 ?., 4:24:12:
> >>
> >>>found by ignoring the bits set in the "don't care mask". I've
> >>>updated the patch at the above URL accordingly and based on my
> >>>testing it now should actually work as expected. Sorry for the
> >>>glitch.
> >> Yes, it works for me.
> >
> >Thanks for testing! I've committed the patch to HEAD and will try
> >to get it into 7.4 and 8.2.
> >
> >> Only one note: I think, it is good idea to document this flag in
> >> re(4).
> >>
> >
> >Technically re.4 obviously is the wrong location for documenting it
> >as it's generally the business of the PHY drivers to handle the media.
> >Moreover, rgephy(4) driven PHYs are also commonly used in combination
> >with at least axe(4), nfe(4), nve(4) and sge(4) MACs so we would have
> >to document this special media option in all of the corresponding man
> >pages, which would introduce undesirable redundancy. So instead I've
> >added a rgephy.4 man page and documented it there.
> >Actually, this is a very good example for why we generally should not
> >document media types and options in the man pages of MAC drivers that
> >take advantage of mii(4) but instead add a common ifmedia.4 and just
> >point there and if as in this case it makes sense to man pages of
> >specific PHY drivers.
>
> First of all, thanks a lot for the work! Can you email me the entire
> set of revisions off-list so that I could have a look, especially to
> see if we can still sneak things into the release after the RC2s (or
> send them to re@ fore pre-review and I'll read them there;)
The revision introducing the flag0 media option for rgephy(4) and
fixing some bugs I'd like to avoid shipping the final 7.4 and 8.2
with is just r217415 and has no dependencies. My idea was to MFC
it to stable/{7,8} as planned and then ask re@ for approval to
merge to release/{7.4,8.2}, pointing at the 2-3 threads on net@
about the problem with servers provided by Hetzner as these appear
to be rather popular even outside of .de (not that I'm affiliated
with them in any way, I'm not even one of their customers).
While working on that I noticed that some other PHY drivers share
similar bugs like the ones fixed by r217415 for rgephy(4) so I
fixed these also, which might make you think that other revisions
committed about the same time might be a dependency of the former.
Unlike the problems discovered in rgephy(4), the known MAC-PHY-
(driver-)combinations to the best of my knowledge currently won't
be able to trigger these bugs for one reason or the other so I
don't intend to get the other revisions merged into 7.4 and 8.2.
As for documenting r217415 that unfortunately took me some more
revisions, i.e. r217464, r217468 and r217475. However, my original
plan actually wasn't to get these also into 7.4 and 8.2 anyway as
I think this too big a change. I think for hotfix-like stuff like
this one it actually is tolerable to not have the flag0 media
option documented in the documentation included in the release.
>
> Second, I start to like the idea of <$phy>.4 in addition to <$mac>.4 man
> pages and .Xrs given our discussion lately on the extra alias options.
> The only drawback I see is that the ifconfig.8 -> <$mac>.4 -> <$phy>.4
> man page chain gets longer and ifconfig generally doesn't reference
> any drivers but miibus.4 does.
Well, from the dmesg, the output of devinfo(8) etc it's easily
deducible that f.e the re0 interface also involves miibusX and
rgephyY instances. So I really think we can expect our users to
think of having a look at all of these man pages might be a good
idea if they intend to configure the interface, especially since
as you also point out ifconfig.8 generally doesn't say much about
drivers. Of course this requires <$mac>.4 to not give the
impression they would be authoritative about the media supported,
which they currently unfortunately do.
> Would it make a sense to add a list of
> man pages of the `phys' implementing miibus in addition to the list of
> drivers making use of miibus, rather than just having adding the .Xr
> at the end? The list might grow in the future now that it was
> started?
>
Yes, having such a list in miibus.4 seems like a good idea.
However, I wanted to avoid touching that man pages more than
really necessary at this time as it IMO is in the need for a
general overhaul; several of the information provided there
more or less obviously refers to how things looked like when
Fast Ethernet was the state of the art or otherwise read
rather strange to me. To be honest in this regard I much
prefer the simplicity of the NetBSD mii.4, which the FreeBSD
miibus.4 at least has been inspired by judging the comment at
the top of that man page. The former talks more about how things
work in the OS and what the user is able to
Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW
On Sun, 16 Jan 2011, Marius Strobl wrote: Hi, On Fri, Jan 14, 2011 at 01:41:09PM +0300, Lev Serebryakov wrote: Hello, Marius. You wrote 14 ?? 2011 ?., 4:24:12: found by ignoring the bits set in the "don't care mask". I've updated the patch at the above URL accordingly and based on my testing it now should actually work as expected. Sorry for the glitch. Yes, it works for me. Thanks for testing! I've committed the patch to HEAD and will try to get it into 7.4 and 8.2. Only one note: I think, it is good idea to document this flag in re(4). Technically re.4 obviously is the wrong location for documenting it as it's generally the business of the PHY drivers to handle the media. Moreover, rgephy(4) driven PHYs are also commonly used in combination with at least axe(4), nfe(4), nve(4) and sge(4) MACs so we would have to document this special media option in all of the corresponding man pages, which would introduce undesirable redundancy. So instead I've added a rgephy.4 man page and documented it there. Actually, this is a very good example for why we generally should not document media types and options in the man pages of MAC drivers that take advantage of mii(4) but instead add a common ifmedia.4 and just point there and if as in this case it makes sense to man pages of specific PHY drivers. First of all, thanks a lot for the work! Can you email me the entire set of revisions off-list so that I could have a look, especially to see if we can still sneak things into the release after the RC2s (or send them to re@ fore pre-review and I'll read them there;) Second, I start to like the idea of <$phy>.4 in addition to <$mac>.4 man pages and .Xrs given our discussion lately on the extra alias options. The only drawback I see is that the ifconfig.8 -> <$mac>.4 -> <$phy>.4 man page chain gets longer and ifconfig generally doesn't reference any drivers but miibus.4 does. Would it make a sense to add a list of man pages of the `phys' implementing miibus in addition to the list of drivers making use of miibus, rather than just having adding the .Xr at the end? The list might grow in the future now that it was started? /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW
On Fri, Jan 14, 2011 at 01:41:09PM +0300, Lev Serebryakov wrote: > Hello, Marius. > You wrote 14 ?? 2011 ?., 4:24:12: > > > found by ignoring the bits set in the "don't care mask". I've > > updated the patch at the above URL accordingly and based on my > > testing it now should actually work as expected. Sorry for the > > glitch. > Yes, it works for me. Thanks for testing! I've committed the patch to HEAD and will try to get it into 7.4 and 8.2. > Only one note: I think, it is good idea to document this flag in > re(4). > Technically re.4 obviously is the wrong location for documenting it as it's generally the business of the PHY drivers to handle the media. Moreover, rgephy(4) driven PHYs are also commonly used in combination with at least axe(4), nfe(4), nve(4) and sge(4) MACs so we would have to document this special media option in all of the corresponding man pages, which would introduce undesirable redundancy. So instead I've added a rgephy.4 man page and documented it there. Actually, this is a very good example for why we generally should not document media types and options in the man pages of MAC drivers that take advantage of mii(4) but instead add a common ifmedia.4 and just point there and if as in this case it makes sense to man pages of specific PHY drivers. Marius ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
bogus 0 len IP packet, was: Hang in VOP_LOCK1_APV on 8-STABLE with NFS.
Ronald has reported having a problem with the FreeBSD NFS client using 8.2-prerelease. I've redirected it here, since it looks like there is a TCP/IP issue that is causing it. > > >> > >> These are the links to the dumps: > >> http://klop.ws/~ronald/nfs-problem/procstat.nolockd > >> http://klop.ws/~ronald/nfs-problem/ps.nolockd > >> http://klop.ws/~ronald/nfs-problem/linux5.nfs.nolockd.dump.gz > >> http://klop.ws/~ronald/nfs-problem/linux5.nfs.with_rpc_patch.dump.gz > >> I looked at the last of these via wireshark and it seems that the FreeBSD client is sending bogus TCP/IP packets with a IP length == 0. (If you look at the above dump (...with_rpc_patch.dump.gz), the first one is at packet #46, then #3024, then persistently starting at #3234.) Basically the packet looks like: frame len: 4446 MAC: dst 00:0d:56:70:b7:6c src b8:ac:6f:47:73:6e type: 08 00 (IP) IP version: 4 header length: 20 differentiated services field: 0x00 total length: 0 - followed by what looks like a legitimate TCP/IP packet Here's the first bytes of the raw packet data: 00 0d 56 70 b7 6c b8 ac 6f 47 73 6e 08 00 45 00 00 00 ... After this packet is sent to the Linux server, it replies with a TCP ack, which gets ACK'd from FreeBSD as well. For the persistent case, it just keeps doing this (bogus 0 length packet from FreeBSD -> Linux server, followed by the two TCP ack packets) over and over and over again, to the end of the dump. So, does anyone have an idea why the IP length field would be set to 0 for these TCP/IP packets? Here's some info from Ronald w.r.t. his hardware. (All I can think of is that he could try disabling TSO, etc?) Thanks in advance for any help with this, rick > > I just looked at the last dump and there seems to be a network > > issue. > > (It first shows up at packet #46, then again at #3025, then > > persistently > > starting at #3234.) > > > > I'd like to post on freebsd-net@ to see if anyone more conversant > > with > > TCP/IP can look, but first I'd like to get a little more info on > > your > > hardware/software config. > > > > In particular, what network hardware does the FreeBSD client use? > > > > And I assume the server is some variant of Linux? > > > > Thanks for creating the tcpdumps, rick > > ps: If you look on wireshark, the problem seems to start with a > > badly formed IP datagram that then causes acks in both > > directions. > > We are getting off list now. I don't know how good that is. > I've redirected it to freebsd-net@ in the hopes that networking folks can help. > But here is some info. I also noticed the bad packets. And my computer > is > resending the same info at quite a high rate (MB/s). > The server is an up-to-date Linux Debian 5 with a 2.6.26-1-686-bigmem > kernel. Colleagues using Linux clients don't have these problems. > > dmesg | grep em0 > em0: port 0xece0-0xecff > mem > 0xf7fe-0xf7ff,0xf7fd9000-0xf7fd9fff irq 21 at device 25.0 on > pci0 > em0: Using an MSI interrupt > em0: [FILTER] > em0: Ethernet address: b8:ac:6f:47:73:6e > > pciconf -lv > em0@pci0:0:25:0: class=0x02 card=0x02761028 chip=0x10de8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel Gigabit network connection (82567LM-3 )' > class = network > subclass = ethernet > > > [root@ronald ~]# ifconfig em0 > em0: flags=8843 metric 0 mtu > 1500 > options=219b > ether b8:ac:6f:47:73:6e > inet 10.1.20.49 netmask 0xff00 broadcast 10.1.20.255 > media: Ethernet autoselect (100baseTX ) > status: active > > Thanks for looking into this. If you need more just let me know. I can > also reproduce the problem and send nfsstat or netstat output or > > Thanks, > Ronald. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154007: [ath] Atheros ar9287 card does not get recognized.
Synopsis: [ath] Atheros ar9287 card does not get recognized. State-Changed-From-To: feedback->open State-Changed-By: linimon State-Changed-When: Sun Jan 16 12:45:33 UTC 2011 State-Changed-Why: feedback received. http://www.freebsd.org/cgi/query-pr.cgi?pr=154007 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE
Hi, Trying to upgrade two Soekris firewalls to 8-STABLE or 8.2-PRERELEASE it appears that carp doesn't work at all. I've set up carp like I've done on many firewall pairs before and they all work correctly. With google, nor in the mailing lists, I could find anything about changes in the way carp get configured but if I missed something I'd be happy to hear that it's my fault. Here's the setup: net5501 test3 10.4.0.4/24 | -+- | | net4801 net4801 test1 test2 sis4: 10.4.0.2/24 sis4: 10.4.0.3/24 carp4:10.4.0.1/24 carp4:10.4.0.1/24 | | | | | | | | | | | | | | | | sis[0-3] connected to other networks, see explanation below. When I ping from test3 to 10.4.0.1, I see the following traffic using tcpdump: test3 # tcpdump -e -n -i vr3 not vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vr3, link-type EN10MB (Ethernet), capture size 96 bytes 12:09:35.121831 00:00:24:c9:30:ff > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.4.0.1 tell 10.4.0.4, length 46 12:09:35.122144 00:00:24:c3:49:91 > 00:00:24:c9:30:ff, ethertype ARP (0x0806), length 60: Reply 10.4.0.1 is-at 00:00:5e:00:01:68, length 46 12:09:35.122173 00:00:24:c9:30:ff > 00:00:5e:00:01:68, ethertype IPv4 (0x0800), length 98: 10.4.0.4 > 10.4.0.1: ICMP echo request, id 40482, seq 0, length 64 test1 # tcpdump -e -n -i sis4 not vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis4, link-type EN10MB (Ethernet), capture size 96 bytes 12:09:34.977570 00:00:24:c9:30:ff > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.4.0.1 tell 10.4.0.4, length 46 12:09:34.977705 00:00:24:c3:49:91 > 00:00:24:c9:30:ff, ethertype ARP (0x0806), length 42: Reply 10.4.0.1 is-at 00:00:5e:00:01:68, length 28 test2 # dump -e -n -i sis4 not vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis4, link-type EN10MB (Ethernet), capture size 96 bytes 12:09:35.090050 00:00:24:c9:30:ff > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.4.0.1 tell 10.4.0.4, length 46 There is an ARP request which is replied to by the carp master (test). the ping to the carp address does not even appear on the sis4 interface of test1. This is the kernel config for test1 and test2: include GENERIC device carp makeoptions MODULES_OVERRIDE="" The relevant rc.conf bits: on test1 hostname="test1" cloned_interfaces="carp1 carp2 carp3 carp4" ifconfig_sis0="xxx.xxx.xxx.41/26" ifconfig_sis1="10.1.0.2/24" ifconfig_sis2="10.2.0.2/24" ifconfig_sis3="10.3.0.2/24" ifconfig_sis4="10.4.0.2/24" ifconfig_carp1="10.1.0.1/24 vhid 101 pass abcd1234 advskew 0" ifconfig_carp2="10.2.0.1/24 vhid 102 pass abcd1234 advskew 0" ifconfig_carp3="10.3.0.1/24 vhid 103 pass abcd1234 advskew 0" ifconfig_carp4="10.4.0.1/24 vhid 104 pass abcd1234 advskew 0" on test2 hostname="test2" cloned_interfaces="carp1 carp2 carp3 carp4" ifconfig_sis0="xxx.xxx.xxx.42/26" ifconfig_sis1="10.1.0.3/24" ifconfig_sis2="10.2.0.3/24" ifconfig_sis3="10.3.0.3/24" ifconfig_sis4="10.4.0.3/24" ifconfig_carp1="10.1.0.1/24 vhid 101 pass abcd1234 advskew 100" ifconfig_carp2="10.2.0.1/24 vhid 102 pass abcd1234 advskew 100" ifconfig_carp3="10.3.0.1/24 vhid 103 pass abcd1234 advskew 100" ifconfig_carp4="10.4.0.1/24 vhid 104 pass abcd1234 advskew 100" In /etc/sysctl.conf: net.inet.carp.preempt=1 Ifconfig output: test1 # ifconfig sis4 sis4: flags=8943 metric 0 mtu 1500 options=83808 ether 00:00:24:c3:49:91 inet 10.4.0.2 netmask 0xff00 broadcast 10.4.0.255 media: Ethernet autoselect (100baseTX ) status: active test1 # ifconfig carp4 carp4: flags=49 metric 0 mtu 1500 inet 10.4.0.1 netmask 0xff00 carp: MASTER vhid 104 advbase 1 advskew 0 test2 # ifconfig sis4 sis4: flags=8943 metric 0 mtu 1500 options=83808 ether 00:00:24:c3:49:7d inet 10.4.0.3 netmask 0xff00 broadcast 10.4.0.255 media: Ethernet autoselect (100baseTX ) status: active test2 # ifconfig carp4 carp4: flags=49 metric 0 mtu 1500 inet 10.4.0.1 netmask 0xff00 carp: BACKUP vhid 104 advbase 1 advskew 100 There are no packet filters in place, sis1, sis2 and sis3 are wired through cross-cables fro
Re: TCP resident expert?
On Sat, 15 Jan 2011, William Allen Simpson wrote: Who's the kernel expert on TCP around here? ISC wants me to port TCPCT to FreeBSD. Although I've joined this list (some time ago), I've not seen any traffic discussing TCP'ish things. Need somebody willing to walk me through the processes and check my code. I don't think there's any single "the" expert -- rather, work on TCP is distributed over a number of developers who take various interests in the topic. At the risk of pointing fingers: Lawrence Stewart has recently been involved in pluggable congestion control, new congestion control algorithms, TCP tracing, and various other things, and has been among our most active hands in TCP for the last year especially. He might be the best first port of call because of this recent activity. Rui Paulo did our TCP ECN support. I've had my hands in TCP data structure/locking/etc on several occasions in the last couple of years, especially relating to SMP scalability, and most recently, TCP connection CPU affinity and hardware-driven load balancing (RSS, etc) as part of work for Juniper. Andrew Opperman has done significant work on features like TSO, LRO, timers, etc in the last couple of years, and before that reworked out TCP syncache implementation (so might be of particular interest). Drew Gallatin was the originator of our LRO code as part of his work at Myricom, and has taken a more general interest in stack performance. Kip Macy (kmacy@) did our TCP offload implementation as part of work for Chelsio. George Neville-Neil has been involved in TCP regression testing, as well as other TCP-related problems in the data centre. Bjoern Zeeb has been involved in our ongoing network stack virtualisation project, and has of necessity had his hands dirty in TCP. And I feel certain there are others who, entirely accidentally and much to my embarrassment, I have omitted. As Doug points out, however, the best way to reach folks interested in TCP is via the freebsd-net@ mailing list, as people come and go some over time, and taking any questions to that list will let the answers get archived. Also, as people do come and go, the mailing list may help your requests not be dropped :-). (I've CC'd that list) Robert ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
