Re: IPMI and bge (again)
On Wed, May 03, 2006 at 08:54:09PM -0700, Doug Ambrisko wrote: > Robert Wojciechowski writes: > | > Could you try this latest version. It incorporates Oleg > | > change sort-of. It was a good hint. The issue is that > | > we can't move the detection after the "reset" dance. Since > | > it needs to know if ASF is active. What we can do is just > | > do the bge_reset, look for ASF and then do the dance. This > | > works really well and I makes the PHY probe work without the > | > one remaining hack that I had left and I was able to get rid > | > of a couple more hacks. > | > > | > This applies to RELENG_6. > | > > | > Please let me know how this works. I'd like to commit > | > this. Please pay attention to if IPMI works before the > | > NIC is UP/or has an IP and then when it is ifconfig down > | > then up again. The PHY should be detected at brgphy > | > and not the generic one. It should also have all of the > | > proper speeds. It should work with and without PXE boot. > | > Finally non-IPMI ones should work. > | > > | > So far it works on the variants I have. > | > | Doug, > | > | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD > | 6.1-RC2 but experienced hard lockups. It happens during startup right > | after setting the hostname, right before it would normally bring up the > | interface I believe. > > Could you try: > http://www.ambrisko.com/doug/bge_ipmi_2.patch > > | This is on four different servers, all Supermicro motherboards (H8DAR > | and H8DAE) based on the Broadcom BCM5704 chip. > | > | Here is the pciconf -lv: > | > | [EMAIL PROTECTED]:3:0: class=0x02 card=0x164815d9 chip=0x164814e4 > rev=0x10 > | hdr=0x00 > | vendor = 'Broadcom Corporation' > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' > | class= network > | subclass = ethernet > | [EMAIL PROTECTED]:3:1: class=0x02 card=0x164815d9 chip=0x164814e4 > rev=0x10 > | hdr=0x00 > | vendor = 'Broadcom Corporation' > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' > | class= network > | subclass = Ethernet > | > | Any ideas? If you need any more information or have other patches I can > | test for you, let me know! > > Try this version. If this has trouble we can try to add some debug > stuff to it. > > Thanks, > > Doug A. I've tested your new patch on hp proliant dl145g2 server with bcm5721 on board chips: bge1: mem 0xca10-0xca10 irq 19 at device 0.0 on pci3 It does work but i've found some problems: minor ones: 1) IPMI stop working for a few seconds while ifconfig bge1 up/down or driver initialization (perhaps this happens when bge_reset() is called) 2) IPMI interface (bound to brgphy1) is unreachable from bge1 itself. I guess it's due to simplex nature of bge. I'm not sure this can be fixed. major one: Driver is unable to detect link loss. Problematic code is in bge_tick_locked: /* Don't mess with the PHY in IPMI/ASF mode */ if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) mii_tick(mii); what purpose of this check? mii_tick() call is necessary for updating phy's link status. -- Oleg. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nd6_lookup prints bogus messages with point to point devices
Hello FreeBSD network folks, On one of the FreeBSD machines we maintain at Dispuut Interlink[1], we get a lot of messages like these: | nd6_lookup: failed to add route for a neighbor(), errno=17 The addresses mentioned in the messages are all addresses of endpoint addresses of point-to-point devices. The nd6_lookup() call in the function nd6_output() is responsible for it. If you look through nd6_output(), you see that a couple of lines below the nd6_lookup() call it doesn't really care when dealing with IFF_POINTOPOINT devices. It would be really useful to drop the messages when dealing with point to point devices, so I write a patch[2] for nd6_lookup() to make it print the message when not dealing with IFF_POINTOPOINT devices. Should I open a PR for this patch? Yours, -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ [1] http://www.il.fontys.nl/ [2] http://g-rave.nl/junk/freebsd-nd6_lookup-spam.diff pgpd8a5XUqqfF.pgp Description: PGP signature
Re: IPMI and bge (again)
Oleg Bulyzhin writes: | On Wed, May 03, 2006 at 08:54:09PM -0700, Doug Ambrisko wrote: | > Robert Wojciechowski writes: | > | > Could you try this latest version. It incorporates Oleg | > | > change sort-of. It was a good hint. The issue is that | > | > we can't move the detection after the "reset" dance. Since | > | > it needs to know if ASF is active. What we can do is just | > | > do the bge_reset, look for ASF and then do the dance. This | > | > works really well and I makes the PHY probe work without the | > | > one remaining hack that I had left and I was able to get rid | > | > of a couple more hacks. | > | > | > | > This applies to RELENG_6. | > | > | > | > Please let me know how this works. I'd like to commit | > | > this. Please pay attention to if IPMI works before the | > | > NIC is UP/or has an IP and then when it is ifconfig down | > | > then up again. The PHY should be detected at brgphy | > | > and not the generic one. It should also have all of the | > | > proper speeds. It should work with and without PXE boot. | > | > Finally non-IPMI ones should work. | > | > | > | > So far it works on the variants I have. | > | | > | Doug, | > | | > | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD | > | 6.1-RC2 but experienced hard lockups. It happens during startup right | > | after setting the hostname, right before it would normally bring up the | > | interface I believe. | > | > Could you try: | > http://www.ambrisko.com/doug/bge_ipmi_2.patch | > | > | This is on four different servers, all Supermicro motherboards (H8DAR | > | and H8DAE) based on the Broadcom BCM5704 chip. | > | | > | Here is the pciconf -lv: | > | | > | [EMAIL PROTECTED]:3:0: class=0x02 card=0x164815d9 chip=0x164814e4 rev=0x10 | > | hdr=0x00 | > | vendor = 'Broadcom Corporation' | > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | > | class= network | > | subclass = ethernet | > | [EMAIL PROTECTED]:3:1: class=0x02 card=0x164815d9 chip=0x164814e4 rev=0x10 | > | hdr=0x00 | > | vendor = 'Broadcom Corporation' | > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | > | class= network | > | subclass = Ethernet | > | | > | Any ideas? If you need any more information or have other patches I can | > | test for you, let me know! | > | > Try this version. If this has trouble we can try to add some debug | > stuff to it. | > | > Thanks, | > | > Doug A. | | I've tested your new patch on hp proliant dl145g2 server with bcm5721 on board | chips: | bge1: mem 0xca10-0xca10 irq 19 at device 0.0 on pci3 | | It does work but i've found some problems: | | minor ones: | 1) IPMI stop working for a few seconds while ifconfig bge1 up/down or driver | initialization (perhaps this happens when bge_reset() is called) This is expected and happens under Linux etc. If it didn't happen then we wouldn't need driver support for it! | 2) IPMI interface (bound to brgphy1) is unreachable from bge1 itself. I guess | it's due to simplex nature of bge. I'm not sure this can be fixed. Correct, if you have a routable connect then you can talk back to your self. | major one: | Driver is unable to detect link loss. Problematic code is in bge_tick_locked: | | /* Don't mess with the PHY in IPMI/ASF mode */ | if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) | mii_tick(mii); | | what purpose of this check? mii_tick() call is necessary for updating phy's | link status. In IPMI enabled we can't read the PHY much since the ASF firmware is also reading it. This can result in lock ups of the firmware :-( Both the driver and the ASF part stops working. So I only allow reads until we have link. I used to be able to detect if IPMI was enabled on the chip and then only prevent the poll in that case. Since your chip needed the reset first we lose that state info. So now I have to assume it on if the chip is capable :-( Linux goes a step further and never reads from the PHY. I've got it so I can read okay during initialization. If I could talk to chip reliably to read the asf stack up state then things would be better on machines that have multiple of these NIC's. Intel doesn't have as much issues. The new bce seems better, however, in DDB is seems IPMI stops working on the bce driver. The doc's don't really go into great detail and we found one chip (5704C) that barf's on: bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); in bge_sig_pre_reset. I'm thinking we might want to try a sysctl to enable IPMI or only do this stuff for IPMI capable chips. Slowly things are getting better. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FW: IPSEC tunnel problem
Hello freebsd-net, I had a problem with IPSEC which is actually already solved on freebsd-pf thanks to list members. I'm forwarding "a solution" here because when I was google-ing for a solution I found similar problems on this list as well. And it looks like these are still unanswered. Examples are: IPSec session stalls ( http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008745.html ) more on IPSec + gif stalling ( http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008812.html ) Also there are still three issues I would like someone experienced take a look at before I start filling PRs :=) Regards, Dmitry Andrianov -Original Message- From: Dmitry Andrianov Sent: Friday, May 05, 2006 4:06 PM To: 'Daniel Hartmeier' Cc: 'freebsd-pf@freebsd.org' Subject: RE: IPSEC tunnel problem Ok, finally, IPSEC_FILTERGIF fixes the problem with stalling connections. Daniel, thanks a lot for your help. However I see at least three issues which needs to be handled somehow: 1. I believe that these days FreeBSD+pf becomes very popular configuration and the fact that system does not work out of the box in this configuration and requires some tricks is not a good sign. My personal opinion is that IPSEC_FILTERGIF just should be on by default. Or at least IPSEC section of FreeBSD handbook should say something about it. Making kernel option on by default has advantage because there are many places with IPSEC how-to on Internet and it is not possible to fix all of them. So the question is should I fill doc/* PR or kernel/* PR for that? 2. Why the router replies with ICMP host-unreachable to the TCP packets with wrong state if block policy is set to "drop" and not "return"? 3. Below is the dump of packets how pf sees 3way handshake with IPSEC_FILTERGIF option 15:22:53.192253 rule 0/0(match): pass in on fxp0: 10.1.0.1 > 10.1.0.2: ESP(spi=0x2708,seq=0x9b05), length 104 15:22:53.192267 rule 0/0(match): pass in on fxp0: 10.1.0.1 > 10.1.0.2: 192.168.10.176.2169 > 10.2.0.2.3389: S 32772:32772(0) win 32768 (ipip-proto-4) 15:22:53.192276 rule 0/0(match): pass in on gif0: 192.168.10.176.2169 > 10.2.0.2.3389: S 32772:32772(0) win 32768 15:22:53.192286 rule 0/0(match): pass out on fxp1: 192.168.10.176.2169 > 10.2.0.2.3389: S 32772:32772(0) win 32768 15:22:53.192436 rule 0/0(match): pass in on fxp1: 10.2.0.2.3389 > 192.168.10.176.2169: S 1559792967:1559792967(0) ack 32773 win 65535 15:22:53.192445 rule 0/0(match): pass out on gif0: 10.2.0.2.3389 > 192.168.10.176.2169: S 1559792967:1559792967(0) ack 32773 win 65535 15:22:53.192460 rule 0/0(match): pass out on fxp0: 10.1.0.2 > 10.1.0.1: ESP(spi=0x2707,seq=0x18a4), length 104 15:22:53.193098 rule 0/0(match): pass in on fxp0: 10.1.0.1 > 10.1.0.2: ESP(spi=0x2708,seq=0x9b06), length 96 15:22:53.193108 rule 0/0(match): pass in on fxp0: 10.1.0.1 > 10.1.0.2: 192.168.10.176.2169 > 10.2.0.2.3389: . ack 1 win 33580 (ipip-proto-4) 15:22:53.193116 rule 0/0(match): pass in on gif0: 192.168.10.176.2169 > 10.2.0.2.3389: . ack 1 win 33580 15:22:53.193123 rule 0/0(match): pass out on fxp1: 192.168.10.176.2169 > 10.2.0.2.3389: . ack 1 win 33580 Clearly, pf sees each packet coming from the tunnel as four (ESP in on WAN interface, ipencap in on WAN interface, in on gif and out packet on LAN interface) while only three packets for data coming from LAN to tunnel. For me this has two disadvantages: * I have to allow ipencap between endpoint in firewall, otherwise decapulated IPSEC packet gets blocked. I do not like this thing because it will also allow someone sending ipencap packets with spoofed source easily. * It is just a bit inconsistent - I would prefer either seeing none of ipencaps (in and out) or seeing them both. I could fill PR about that one too, but I'm not sure what is the best way to propose. Regards, Dmitry Andrianov -Original Message- From: Dmitry Andrianov Sent: Friday, May 05, 2006 1:42 AM To: 'Daniel Hartmeier' Cc: freebsd-pf@freebsd.org Subject: RE: IPSEC tunnel problem Daniel, Looks like you are right. Below is dump from pflog0 interface of 3way handshake to 3389: 01:27:55.888031 rule 0/0(match): pass out on fxp1: 192.168.10.176.3809 > 10.2.0.2.3389: S 220200183:220200183(0) win 32768 01:27:55.888177 rule 0/0(match): pass in on fxp1: 10.2.0.2.3389 > 192.168.10.176.3809: S 1690303870:1690303870(0) ack 220200184 win 65535 01:27:55.888186 rule 0/0(match): pass out on gif0: 10.2.0.2.3389 > 192.168.10.176.3809: S 1690303870:1690303870(0) ack 220200184 win 65535 01:27:55.84 rule 0/0(match): pass out on fxp1: 192.168.10.176.3809 > 10.2.0.2.3389: . ack 1 win 33580 Packets coming from the VPN only appear as "out" packets on LAN ethernet. While packets coming from LAN appear as "in" packets on ethernet and "out" packets on gif. I assume this is because my kernel was not build with # Set IPSEC_FILTERGIF to force packets coming through a gif tunnel # to be processed by any configured pac
