Re: kern/145777: [wpi] Intel 3945ABG driver breaks the connection after about 10 minutes of inactivity
The following reply was made to PR kern/145777; it has been noted by GNATS. From: =?UTF-8?B?0KjQsNC80LDQvdC+0LIg0JDQu9C10LrRgdC10Lk=?= atsha...@gmail.com To: bug-follo...@freebsd.org, marcin.no...@simplusnet.pl Cc: Subject: Re: kern/145777: [wpi] Intel 3945ABG driver breaks the connection after about 10 minutes of inactivity Date: Tue, 26 Oct 2010 12:45:02 +0600 --0016368e1f24cc5d8004937f7287 Content-Type: text/plain; charset=UTF-8 Try to use ifconfig with '-powersave' option. --0016368e1f24cc5d8004937f7287 Content-Type: text/html; charset=UTF-8 Try to use ifconfig with #39;-powersave#39; option. br --0016368e1f24cc5d8004937f7287-- ___ 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: Problems with 8.1, PPPoE server, and Cisco client
I've been taking another look at this after being dragged off onto other things for a few days, and hopefully have some more information that might help point in the right direction for a fix / where to debug next. On 20/10/2010 17:16, Julian Elischer wrote: have you tried to connect this cisco router to anything else pppoe? (take it home and make it connect to your ISP for example?) The Cisco client does work to a Cisco router acting as a PPPoE server - I used a 891 (client) to a 3945 (server) and using an established setup that is known to work, I collected a happy tcpdump. Of course that doesn't tell us why there was such an issue with the FreeBSD ppp server and it looks very similar to me. I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. Thanks to everyone for their help with this. So here is the dump from a known good setup, IOS at both ends - starting from the CHAP success point again. This time, both ends play the game and agree amongst themselves what they will and won't do as expected (many thanks to Ian here for the commentary as to what was going on in the exchanges I have): 20:29:10.200860 PPPoE [ses 0x13] CHAP, Response (0x02), id 1, Value 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01, Name vt123456...@vdsl01.v 20:29:14.501312 PPPoE [ses 0x13] CHAP, Success (0x03), id 1, Msg 20:29:14.501702 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.504344 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 0.0.0.0 0x: 20:29:14.504497 PPPoE [ses 0x13] unknown PPP protocol (0x8207) 0x: 0101 0004 20:29:14.504669 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0201 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.505200 PPPoE [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0301 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.505290 PPPoE [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: c021 0802 000a Rejected unknown Protocol (0x8207) Rejected Packet 0x: 0101 0006 20:29:14.505800 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0102 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.506753 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0202 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:23.247975 PPPoE [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, flags [none], proto ICMP (1), length 100) 109.71.174.50 217.65.161.4: ICMP echo request, id 10, seq 0, length 80 20:29:23.257872 PPPoE [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, flags [none], proto ICMP (1), length 100) 217.65.161.4 109.71.174.50: ICMP echo reply, id 10, seq 0, length 80 The ping here is the start of real data flowing - I used this setup for about 30 minutes of web browsing with no problems. Paul. ___ 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: driver for broadcom 57711E
Hello, On 07.10.2010 09:07, Дмитрий Александров wrote: Hi! I really need broadcom 57711E driver for my FreeBSD 8.0 i386. Does anybody have this driver already? P.S. Also wanted David Christensen who had previously tried to write a driver. LOL. Welcome to the club :-) ( Though I'm afraid David, or Broadcomm, respectively, are incommunicado on this particular issue. ) Let us know if you hear something different. Regards Christoph Weber-Fahr ___ 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: driver for broadcom 57711E
On Tue, Oct 26, 2010 at 07:30:19PM +0200, Christoph Weber-Fahr wrote: Hello, On 07.10.2010 09:07, Дмитрий Александров wrote: Hi! I really need broadcom 57711E driver for my FreeBSD 8.0 i386. Does anybody have this driver already? P.S. Also wanted David Christensen who had previously tried to write a driver. LOL. Welcome to the club :-) ( Though I'm afraid David, or Broadcomm, respectively, are incommunicado on this particular issue. ) Let us know if you hear something different. Actually David is very responsive but I think he is somewhat busy for other work. For example, I had been working with David to support next generation Broadcom controller that would be widely available in next year. Personally I haven't have chance to try bnx(4) which was written by David to support BCM57710/57711/57711E controllers so I don't know how well it works. As David said long time ago, one of issue was testing wide variety of PHYs used in controller such that it made hard to release the driver. David, would you clarify current status of bnx(4)? ___ 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: driver for broadcom 57711E
On Tue, Oct 26, 2010 at 11:21:21AM -0700, Pyun YongHyeon wrote: On Tue, Oct 26, 2010 at 07:30:19PM +0200, Christoph Weber-Fahr wrote: Hello, On 07.10.2010 09:07, Дмитрий Александров wrote: Hi! I really need broadcom 57711E driver for my FreeBSD 8.0 i386. Does anybody have this driver already? P.S. Also wanted David Christensen who had previously tried to write a driver. LOL. Welcome to the club :-) ( Though I'm afraid David, or Broadcomm, respectively, are incommunicado on this particular issue. ) Let us know if you hear something different. Actually David is very responsive but I think he is somewhat busy for other work. For example, I had been working with David to support next generation Broadcom controller that would be widely available in next year. Personally I haven't have chance to try bnx(4) which was written by David to support BCM57710/57711/57711E controllers so I don't know how well it works. As David said long time ago, one of issue was testing wide variety of PHYs used in controller such that it made hard to release the driver. David, would you clarify current status of bnx(4)? Actually the driver name was bxe(4). ___ 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
Bridge problems, possibly due to proxy arp on Parallels Desktop
Summary To make a ping from a OpenVPN client using TAP work, I have to set the bridge interface manually using ifconfig bridge0 static tap0 Ethernet_addr on the server. My setup Host 3dosexp IP 192.168.0.220 on tap0 FreeBSD 8.1, OpenVPN client using tap0 interface This is a Virtual Machine on Parallels Desktop 6.0 for Mac OS X It has one virtual NIC which is on Desktop host-only network which is used for the the encrypted channel for OpenVPN Host Eight IP 192.168.0.8 on bridge0. FreeBSD 8.1, OpenVPN server using bridged networking. This is another VM on Desktop. It has one virtual NIC on host-only networking which is used for the other end of the OpenVPN link. It has another NIC on Desktop bridged networking (not the same as OpenVPN) with IP 192.168.0.8 on interface em0 Host Two IP 192.168.0.2 on en1 Mac OS X 10.6 This is a real machine. Interface en1 is bridged by Desktop en1 is a wifi interface. It connects to:- Router One IP 192.168.0.1 Netgear DG834G wireless and 4-port router. Host 3dos IP 192.168.0.250 on vr0 PC running FreeBSD 8.1 i386 Connected via cable to the router. It is destined to become a VPN server in a small office when the networking starts working. -- Problem One Pinging from Host 3dosexp to Host Two does not work. Running ifconfig bridge0 addr on host Eight to see what interfaces are used for which ethernet address shows that all interfaces are set to em0. Setting a static interface to tap0 for the ethernet address assigned to tap0 on host 3dosexp makes the ping work. ( using ifconfig bridge0 static tap0 3dosexp-ethernet-address ) Running ifconfig bridge0 flushall on host Eight stops the ping working. ifconfig bridge0 addr shows the ethernet address for host 3dosexp is now set back to interface em0. -- Problem two Run the command for setting the static interface as described in problem one. Trying a ping from host 3dosexp (VPN client) to host 3dos ( attached to the router) does not work. Ping responds with ping: sendto: Host is down On host Eight (the VPN server) running tcpdump on interface em0 shows that there are arp requests Who has 192.168.0.250 tell 192.168.0.220 and arp replies from host 192.168.0.250. The destination of the arp replies is the ethernet address of interface em0. The replies never get through the bridge and out onto interface tap0. That's almost true, but sometimes something seems to flip and ping starts sending ICMP echo requests. Again, looking at the interfaces with tcpdump shows ICMP requests and replies on interface em0. The replies have an ethernet destination of the ethernet address of em0. Surely they should be destined for host 3dosexp (the client). The replies do not make it through the bridge. I suspect at the moment that this is something to do with Desktop bridged networking using Proxy ARP between the virtual and real networks. ifconfig for host Eight (the VPN server) em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=98VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:1c:42:01:3f:6c media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:1c:42:f2:f0:b0 inet 10.37.129.3 netmask 0xff00 broadcast 10.37.129.255 media: Ethernet autoselect (1000baseT full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 nd6 options=3PERFORMNUD,ACCEPT_RTADV tap0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8LINKSTATE ether 00:bd:75:26:00:00 Opened by PID 1391 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 6e:67:0a:b1:17:91 inet 192.168.0.8 netmask 0xff00 broadcast 192.168.0.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 4 priority 128 path cost 200 member: em0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 1 priority 128 path cost 2 - bridge startup script (immediately after reboot has finished) #!/bin/sh ifconfig tap0 down ifconfig bridge0 down ifconfig bridge0 destroy ifconfig tap0 destroy ifconfig tap0 create ifconfig tap0 up ifconfig em0 up ifconfig bridge0 create ifconfig bridge0 addm em0 addm tap0 up ifconfig bridge0 inet 192.168.0.8 netmask 255.255.255.0 - routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire 10.37.129.0/24 link#2 U 1 165em1
RE: driver for broadcom 57711E
Hi! I really need broadcom 57711E driver for my FreeBSD 8.0 i386. Does anybody have this driver already? P.S. Also wanted David Christensen who had previously tried to write a driver. LOL. Welcome to the club :-) ( Though I'm afraid David, or Broadcomm, respectively, are incommunicado on this particular issue. ) Actually David is very responsive but I think he is somewhat busy for other work. For example, I had been working with David to support next generation Broadcom controller that would be widely available in next year. Personally I haven't have chance to try bnx(4) which was written by David to support BCM57710/57711/57711E controllers so I don't know how well it works. As David said long time ago, one of issue was testing wide variety of PHYs used in controller such that it made hard to release the driver. David, would you clarify current status of bnx(4)? Actually the driver name was bxe(4). Sorry for the delays on keeping the community updated on the status of the bxe(4) driver. If someone is willing to review the driver and help us address some of the style(9) violations in the source code, I'll commit the code within two weeks. Please email me off-list if you're able to help. Dave ___ 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
