Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
> > May be linux driver defaults to full-duplex if autoneg fails?.. > > I've seen some Linux drivers fail back to half-duplex under these > circumstances. > > It may very well depend on driver version and hardware (firmware)? > > I admit, I don't know what layer is responsible for handling > autonegotiation... It should be noted that fallback to half-duplex when autoneg fail is actually *required* by the IEEE Ethernet standards. We may not like it, but there it is... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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: IPFW firewall NAT and active FTP
12.01.2011 01:06, Brett Glass пишет: I'm working with a customer who has a FreeBSD 8.0 firewall, set up with firewall NAT in IPFW. It uses one-to-one static NAT to redirect FTP sessions originating on the outside to an FTP server on the inside. The FTP server is accessible via text-based FTP clients, but not via Web-based clients such as Mozilla Firefox or Internet Explorer. The internal FTP server is also a FreeBSD machine. Does FTP server enforces any limits for sessions per ip? In past I saw that IE can open up to four concurrent sessions. If plain text ftp clients works, IMHO it's not a NAT problem. Also check config of ipfw is it supports both active and passive FTP transfers. He's wondering if the problem has to do with the lack of a "firewall punching" setting (which exists in natd but not in IPFW's built-in NAT). Can anyone suggest what might be causing the problem? --Brett Glass ___ 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" -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | JID: ar...@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org ___ 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: Supermicro Bladeserver
On Wed, Jan 12, 2011 at 03:13 -, you wrote: > Out of interest what change was that? As what seems to have been a left-over from a debugging session a long time ago, I had MSI disabled in loader.conf. That's not supported by the driver. So simply reenabling that solved my problem. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org ___ 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: Supermicro Bladeserver
Out of interest what change was that? - Original Message - From: "Vogel, Jack" To: "TAKAHASHI Yoshihiro" ; Cc: ; Sent: Monday, January 10, 2011 9:17 PM Subject: RE: Supermicro Bladeserver We attempted to repro this problem with the 82566DM (ich8 btw) in house and failed, it worked correctly for my testers. Oh, and just so the mailing lists have an update, the SM Blade problem was not an issue in the driver, it was a local change in the loader.conf that caused the problem. 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-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPFW firewall NAT and active FTP
I'm working with a customer who has a FreeBSD 8.0 firewall, set up with firewall NAT in IPFW. It uses one-to-one static NAT to redirect FTP sessions originating on the outside to an FTP server on the inside. The FTP server is accessible via text-based FTP clients, but not via Web-based clients such as Mozilla Firefox or Internet Explorer. The internal FTP server is also a FreeBSD machine. He's wondering if the problem has to do with the lack of a "firewall punching" setting (which exists in natd but not in IPFW's built-in NAT). Can anyone suggest what might be causing the problem? --Brett Glass ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Wed, Jan 12, 2011 at 12:31:10AM +0300, Lev Serebryakov wrote: > Hello, Pyun. > You wrote 11 января 2011 г., 23:00:07: > > > rgephy(4) currently always use auto-negotiation to work-around link > > establishment issues reported in past. > I think, it is the root of the problem. Autonegotiation is DISABLED on > these ports. I think, some additional mediaopt (like > force-half-duplex) for rgephy(4) will be solution. > > > For your case, the only way to address the issue at this moment is > > to use auto-negotiation but that would establish 1000baseT link > > which would add cost for you. Alternatively request half-duplex > > configuration to the provider to get a agreed link duplex. >Maybe, adding new mediaopt is not very hard? Or is it? > That had been supported for long time. Just remove full-duplex media option in your manual configuration. ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, Jan 11, 2011 at 10:37:31PM +0300, Lev Serebryakov wrote: > Hello, Brian. > You wrote 11 ?? 2011 ?., 22:29:13: > > > basic mode: 100 Mbit, full duplex > > link partner: 100baseTx-HD > It looks VERY strange. How could id be? This is normal if the link partner doesn't do autonegotiation. The system has to assume a simple repeater hub and do half duplex. If on the other hand the switch is hard set to full-duplex then they can't expect autonegotiation to do it right. However hard setting under FreeBSD as well should work. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, Jan 11, 2011 at 10:50:49PM +0300, Lev Serebryakov wrote: > Hello, Artyom. > You wrote 11 ?? 2011 ?., 22:39:33: > > >>link partner: 100baseTx-HD > > ^ > > Looks very strange for me... 'HD' means half-duplex? > Yep, I've noticed that too... > > > May be linux driver defaults to full-duplex if autoneg fails?.. > Or disabled... And it works -- very strange. And FreeBSD uses > half-duplex even with given "media-opt" and network is dramatically > slow -- NFS from DC-local server is about 150KiB/s (from FreeBSD > installer). > I'm not surprised that it doesn't work with autonegotian if autonegotian is disabled. If Linux does full-duplex without autonegotiation then _they_ do it wrong and Hetzner shouldn't rely on wrong behavour. However since you seem to have access it might be interesting to know the exact network device and debug why hard setting is broken. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
Hello, Pyun. You wrote 11 января 2011 г., 23:00:07: > rgephy(4) currently always use auto-negotiation to work-around link > establishment issues reported in past. I think, it is the root of the problem. Autonegotiation is DISABLED on these ports. I think, some additional mediaopt (like force-half-duplex) for rgephy(4) will be solution. > For your case, the only way to address the issue at this moment is > to use auto-negotiation but that would establish 1000baseT link > which would add cost for you. Alternatively request half-duplex > configuration to the provider to get a agreed link duplex. Maybe, adding new mediaopt is not very hard? Or is it? -- // Black Lion AKA Lev Serebryakov ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
Hello, Artyom. You wrote 11 января 2011 г., 22:57:17: > Is it possible to see status from corresponding port on Juniper switch? > Config part for this port on the switch would be also very interesting. I (as customer with server which has problem) could ask techsupport tomorrow. But, maybe, they didn't answer, because I already have answer that FreeBSD is not supported :( -- // Black Lion AKA Lev Serebryakov ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, Jan 11, 2011 at 01:53:30PM +0300, Lev Serebryakov wrote: > Hello, Yamagi. > You wrote 11 ?? 2011 ?., 13:30:23: > > > Hi, > > I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs > > just fine. I've never seen this strange negotiation problem myself. But > > maybe I was just lucky and got working mainboard and nic combinations. > > So if further information is needed, I'm happy to provide it. > It is known, that problems are in DC 13 and everything wotrks fine > in DC 11 and DC 12. > > I've discussed this problem in local (Russian-speaking) FreeBSD > community, and there are several people in DC 13 who HAVE these > problems and found different solutions, but all non-technical ones: > order gigabit connectivity, or pay for moving servers to other (old) > DCs... > If the latter means that the servers are physically moved as opposed to a new one being allocated this implies that re(4)/rgephy(4) isn't the sole factor responsible for this problem. In any case it would be helpful to have the corresponding dmesg bits as the Linux counterpart does some black magic for certain hardware versions when setting the media manually but re(4) doesn't which might be relevant in this scenario. 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"
Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, 11 Jan 2011, Artyom Viklenko wrote: 11.01.2011 21:48, Bjoern A. Zeeb : On Tue, 11 Jan 2011, Artyom Viklenko wrote: 11.01.2011 21:29, Lev Serebryakov ?: r...@rescue ~ # mii-tool -v eth0 eth0: 100 Mbit, full duplex, link ok product info: vendor 00:07:32, model 17 rev 2 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-HD ^ Looks very strange for me... 'HD' means half-duplex? May be linux driver defaults to full-duplex if autoneg fails?.. That's probably just because it cannot tell what the peer really uses (autoneg disabled) and prints the sane fall-back but I don't know the code. Is it possible to see status from corresponding port on Juniper switch? Config part for this port on the switch would be also very interesting. No but I think we are not getting anywhere; I contacted them this afternoon and will see if they'll get back to me. /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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, Jan 11, 2011 at 12:47:29PM +0300, Lev Serebryakov wrote: > Hello, Freebsd-net. > > Very large and famous (due to very attractive prices) hosting > provider Hetzner.de discards FreeBSD support on dedicated servers, > because these servers can niot negotiate 100Mbit/DUPLEX when > switches' ports are limited to 100Mbit (1Gbit connection costs > additional money) only under FreeBSD. Linux works fine. > > Switches known to be Juniper e3k series. > > MoBos of servers are different assortment of MSI MoBos with Realtek > (re driver) network-on-board. > > Symptjms are: NIC can not negotiate/set duplex when switch port is > limited to 100Mbit/Duplex. Duplex can not be set even manually via > "ifconfig": > > > media: Ethernet 100baseTX (100baseTX ) > > Is it know problem? Maybe, -CURRENT driver has fix for it? > > Unfortunately, I can not provide more information, as I don't have > server at Hetzner (I'm planning to order one, but due to these > problems, I'm not sure now, as I need FreeBSD), and all this > information is collected in communication with people who HAVE servers > with FreeBSD installed. > > Again, I know, that Realtek NICs are crap, but "everybody says" that > Linux doesn't have THIS problem with THESE boards and switches. > I can see what's going on here. Link partner used forced media configuration, probably 100baseTX/full-duplex, and re(4)'s resolved link is 100baseTX/half-duplex. rgephy(4) currently always use auto-negotiation to work-around link establishment issues reported in past. I don't know how Linux managed to address link establishment issues for non-autonegotiation case though. Perhaps a lot of vendor supplied DSP fixups addressed that issue but I'm not sure. For your case, the only way to address the issue at this moment is to use auto-negotiation but that would establish 1000baseT link which would add cost for you. Alternatively request half-duplex configuration to the provider to get a agreed link duplex. See http://lists.freebsd.org/pipermail/freebsd-amd64/2011-January/013589.html for details on parallel detection. ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, Jan 11, 2011 at 09:39:33PM +0200, Artyom Viklenko wrote: > 11.01.2011 21:29, Lev Serebryakov ?: > Looks very strange for me... 'HD' means half-duplex? > > May be linux driver defaults to full-duplex if autoneg fails?.. I've seen some Linux drivers fail back to half-duplex under these circumstances. It may very well depend on driver version and hardware (firmware)? I admit, I don't know what layer is responsible for handling autonegotiation... > ___ > 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" -- Brian Reichert 55 Crystal Ave. #286 Derry NH 03038-1725 USA BSD admin/developer at large ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
11.01.2011 21:48, Bjoern A. Zeeb пишет: On Tue, 11 Jan 2011, Artyom Viklenko wrote: 11.01.2011 21:29, Lev Serebryakov ?: r...@rescue ~ # mii-tool -v eth0 eth0: 100 Mbit, full duplex, link ok product info: vendor 00:07:32, model 17 rev 2 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-HD ^ Looks very strange for me... 'HD' means half-duplex? May be linux driver defaults to full-duplex if autoneg fails?.. That's probably just because it cannot tell what the peer really uses (autoneg disabled) and prints the sane fall-back but I don't know the code. Is it possible to see status from corresponding port on Juniper switch? Config part for this port on the switch would be also very interesting. -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | JID: ar...@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
Hello, Artyom. You wrote 11 января 2011 г., 22:39:33: >>link partner: 100baseTx-HD > ^ > Looks very strange for me... 'HD' means half-duplex? Yep, I've noticed that too... > May be linux driver defaults to full-duplex if autoneg fails?.. Or disabled... And it works -- very strange. And FreeBSD uses half-duplex even with given "media-opt" and network is dramatically slow -- NFS from DC-local server is about 150KiB/s (from FreeBSD installer). -- // Black Lion AKA Lev Serebryakov ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, 11 Jan 2011, Artyom Viklenko wrote: 11.01.2011 21:29, Lev Serebryakov ?: r...@rescue ~ # mii-tool -v eth0 eth0: 100 Mbit, full duplex, link ok product info: vendor 00:07:32, model 17 rev 2 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-HD ^ Looks very strange for me... 'HD' means half-duplex? May be linux driver defaults to full-duplex if autoneg fails?.. That's probably just because it cannot tell what the peer really uses (autoneg disabled) and prints the sane fall-back but I don't know the code. /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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
Hello, Marius. You wrote 11 января 2011 г., 22:36:44: >> I've discussed this problem in local (Russian-speaking) FreeBSD >> community, and there are several people in DC 13 who HAVE these >> problems and found different solutions, but all non-technical ones: >> order gigabit connectivity, or pay for moving servers to other (old) >> DCs... > If the latter means that the servers are physically moved as opposed > to a new one being allocated this implies that re(4)/rgephy(4) isn't > the sole factor responsible for this problem. In any case it would be It is known, that DC 13 has new Juniper e3k switches, and older DCs have older Juniper equipment. > helpful to have the corresponding dmesg bits as the Linux counterpart > does some black magic for certain hardware versions when setting the > media manually but re(4) doesn't which might be relevant in this > scenario. Here it is from Rescue FreeBSD system: re0: port 0xe800-0xe8ff mem 0xfbeff000-0xfbef,0xf8ff-0xf8ff irq 16 at device 0.0 on pci6 re0: Using 1 MSI messages re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 6c:62:6d:a7:bb:37 re0: [FILTER] And, please note very strange output from Linux's mii-tool and ethtool in previous my message to list: mismatch between "basic mode" and "link partner". -- // Black Lion AKA Lev Serebryakov ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
11.01.2011 21:29, Lev Serebryakov пишет: Hello, Brian. You wrote 11 января 2011 г., 19:38:25: Very large and famous (due to very attractive prices) hosting provider Hetzner.de discards FreeBSD support on dedicated servers, because these servers can niot negotiate 100Mbit/DUPLEX when switches' ports are limited to 100Mbit (1Gbit connection costs additional money) only under FreeBSD. Linux works fine. How are the switches being forced to 100/full? I don't know, I never work with Juniper e3k switches (And any other Juniper products at all). All I know, that older Juniper Switches in not-so-new DCs of same provider doesn't have this problem, and, on other hand, Linux and Windows 2008 don't have problems with new ones too. If they're doing so by disabling autonegotiation, then that's where some grief may come from. Linux work with autonegotiation, as I can see (It is outpuit from Rescue Linux system on SAME my server, where FreeBSD shows half-duplex even if forced to full-duplex): r...@rescue ~ # mii-tool -v eth0 eth0: 100 Mbit, full duplex, link ok product info: vendor 00:07:32, model 17 rev 2 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-HD ^ Looks very strange for me... 'HD' means half-duplex? May be linux driver defaults to full-duplex if autoneg fails?.. r...@rescue ~ # ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: No Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: off Supports Wake-on: pumbg Wake-on: g Current message level: 0x0033 (51) Link detected: yes r...@rescue ~ # So, it seems, that autonegotiation is disabled, but it works for Linux, and manual setting of media and mediaopt doesn't help FreeBSD. Also, please note, that when port is in 1Gib mode (which can be buyed for additional money, which I can not afford) FreeBSD works fine. -- Sincerely yours, Artyom Viklenko. --- ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem ar...@viklenko.net | JID: ar...@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
Hello, Brian. You wrote 11 января 2011 г., 22:29:13: > basic mode: 100 Mbit, full duplex > link partner: 100baseTx-HD It looks VERY strange. How could id be? -- // Black Lion AKA Lev Serebryakov ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
Hello, Brian. You wrote 11 января 2011 г., 19:38:25: >> Very large and famous (due to very attractive prices) hosting >> provider Hetzner.de discards FreeBSD support on dedicated servers, >> because these servers can niot negotiate 100Mbit/DUPLEX when >> switches' ports are limited to 100Mbit (1Gbit connection costs >> additional money) only under FreeBSD. Linux works fine. > How are the switches being forced to 100/full? I don't know, I never work with Juniper e3k switches (And any other Juniper products at all). All I know, that older Juniper Switches in not-so-new DCs of same provider doesn't have this problem, and, on other hand, Linux and Windows 2008 don't have problems with new ones too. > If they're doing so by disabling autonegotiation, then that's where > some grief may come from. Linux work with autonegotiation, as I can see (It is outpuit from Rescue Linux system on SAME my server, where FreeBSD shows half-duplex even if forced to full-duplex): r...@rescue ~ # mii-tool -v eth0 eth0: 100 Mbit, full duplex, link ok product info: vendor 00:07:32, model 17 rev 2 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-HD r...@rescue ~ # ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: No Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: off Supports Wake-on: pumbg Wake-on: g Current message level: 0x0033 (51) Link detected: yes r...@rescue ~ # So, it seems, that autonegotiation is disabled, but it works for Linux, and manual setting of media and mediaopt doesn't help FreeBSD. Also, please note, that when port is in 1Gib mode (which can be buyed for additional money, which I can not afford) FreeBSD works fine. -- // Black Lion AKA Lev Serebryakov ___ 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: PPP and Route Delete
> The self-pointing route 10.0.5.1 should have multiple references set on > it, and that route won't be deleted from the routing table until the > last reference is removed. > > You can verify that by checking the "netstat" output, the "Ref" column > after tun1 has been created. > > The above has been verified with both mpd and other tests. Thank you! The bit I had neglected to mention (as the bug report suggested it was a problem with the local route table) was that we are re-distributing routes using openbgpd. I have confirmed that the openbgpd code has no concept of this reference counting and simply removes the route from the table that is being sent out. Sorry for the noise - I should have spotted that myself :( Mel ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, Jan 11, 2011 at 12:47:29PM +0300, Lev Serebryakov wrote: > Hello, Freebsd-net. > > Very large and famous (due to very attractive prices) hosting > provider Hetzner.de discards FreeBSD support on dedicated servers, > because these servers can niot negotiate 100Mbit/DUPLEX when > switches' ports are limited to 100Mbit (1Gbit connection costs > additional money) only under FreeBSD. Linux works fine. How are the switches being forced to 100/full? If they're doing so by disabling autonegotiation, then that's where some grief may come from. If it's not, then ignore the rest of this email. :) For certain hardware combos, I've seen even Linux servers (on Dell hardware) fail to autonegotiate properly. Here's the set of litany I trot out when I have to deal with customer's issues surrounding gigabit and autonegotiation: - With the advent of 1000T networking, the specs says that autonegotation needs to be enabled: http://etherealmind.com/2008/07/15/ethernet-autonegotiation-works-why-how-standard-should-be-set/ " A major problem is that many people are also hard setting Gigabit Ethernet, and this is causing major problems. Gigabit Ethernet must have auto-negotiation ENABLED to allow negotiation of master / slave PHY relationship for clocking at the physical layer. Without negotiation the line clock will not establish correctly and physical layers problems can result." Further, this doc from Dell: http://www.dell.com/content/topics/global.aspx/power/en/ps1q01_hernan?c=us&cs=555&l=en&s=biz Cites: "In addition, the 1999 standard for Gigabit over copper cabling, IEEE Std 802.3ab, added the following enhancements to the Auto-Negotiation standard:" * Mandatory auto-negotiation for 1000BaseT * Configure master and slave modes for the PHY Further: http://en.wikipedia.org/wiki/Autonegotiation "The debatable portions of the autonegotiation specifications were eliminated by the 1998 version of IEEE 802.3. In 1999, the negotiation protocol was significantly extended by IEEE 802.3ab, which specified the protocol for gigabit Ethernet, making autonegotiation mandatory for 1000BASE-T gigabit Ethernet over copper." > ___ > 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" -- Brian Reichert 55 Crystal Ave. #286 Derry NH 03038-1725 USA BSD admin/developer at large ___ 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: PPP and Route Delete
The self-pointing route 10.0.5.1 should have multiple references set on it, and that route won't be deleted from the routing table until the last reference is removed. You can verify that by checking the "netstat" output, the "Ref" column after tun1 has been created. The above has been verified with both mpd and other tests. -- Qing From: owner-freebsd-...@freebsd.org on behalf of Melissa Jenkins Sent: Tue 1/11/2011 3:34 AM To: freebsd-net@freebsd.org Subject: Re: PPP and Route Delete > I've been working on migrating a PPTP server from FreeBSD 7.1 to FreeBSD 8.1. > The server is configured using PopTop (from ports) and PPP (/usr/sbin) > rather than MPD. (Before anybody tells me to use MPD we can't because it > doesn't inject packets into the kernel in the same way and it's not possible > to filter on them correctly) > > Basic PPTP connection works properly. > > The fun happens when I have two simultaneous users. The first one to > DISCONNECT deletes the routes for both of them and all PPTP traffic ceases. Just been working my way through the PPP code - which doesn't actually appear to have changed. However, the netinet/in.c does have some comments in the SVN history about deleting the loopback address, this appears to have been merged in as part of the 8 release cycle (r197231 perhaps) (though I'm not an expert at SVN etc) What should happen when there are multiple interfaces with the same address. When I have two tunnels configured they show up as (eg) tun0: flags=8051 metric 0 mtu 1398 options=8 inet 10.0.5.1 --> 10.0.0.31 netmask 0x Opened by PID 12616 tun1: flags=8051 metric 0 mtu 1398 options=8 inet 10.0.5.1 --> 10.0.0.32 netmask 0x Opened by PID 12630 If the loop back address is 10.0.5.1 and closing one of them deletes the loopback what should happen? Should it delete all routes that refer to 10.0.5.1? Mel ___ 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" ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, 11 Jan 2011, Bjoern A. Zeeb wrote: I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs just fine. I've never seen this strange negotiation problem myself. But maybe I was just lucky and got working mainboard and nic combinations. So if further information is needed, I'm happy to provide it. A lot of us do. There is a problem with the re(4) setup as well in that if you do not send packets out yourself the port takes a very long time to come up and unblocked. I haven't discussed that with them or tested with an updated HEAD (since end of October). I never said that this problems doesn't exists. :) Lev Serebryakov said that everythings works fine in DC11 and DC12, my servers are in DC12. so I was just lucky... But yes, I am running HEAD on an EQ4 as well. If you have problems and a personal email contact at Hetzner feel free to talk to me. I am "local" (a couple of 100km away in the same country) and a FreeBSD committer and I can probably figure things out with them or properly proxy requests. Sadly no. My only contact to Hetzner is the service e-mail adress and the phone number for business clients. They are for all customers and probably can't help with such problems. There are special technical contacts for each DC, but those are only available for customers with hardware in that DC and with specific problems. So someone with a server in DC13 could write a service request in which the problem is explained and ask for help. Maybe they're willing ton assistent in tracking down and solving the problem. Ciao, Yamagi -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB ___ 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: em driver, 82574L chip, and possibly ASPM
On 11/01/2011 15:04, Mike Tancsa wrote: On 12/24/2010 5:44 PM, Jan Koum wrote: hi Ivan and Mike, wanted to follow up and see if you found a solid long-term solution to this bug. we are still seeing this problem in our 8.2 environment with ASPM already disabled. here is what we have: 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: Hi Jack, Looks like this problem is not completely gone :( I have seen it now on 2 different machines. On the RELENG_7, ASPM was enabled in the BIOS (INTEL DH55TC MB), so I have disabled that for now to see what happens. On the RELENG_8 machine, its been a LOT better since 7.1.8, but again it happened last night during a backup My machine is still holding up but it doesn't yet handle full traffic. I've just noticed something strange: both em0 and em1 are marked "active" in ifconfig even though there's no cable in em1 port :( em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:25:90:0b:77:5c inet 10.10.0.33 netmask 0xff00 broadcast 10.10.0.255 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8802 metric 0 mtu 1500 options=219b ether 00:25:90:0b:77:5d media: Ethernet autoselect (100baseTX ) status: active (100 mbit is expected) Note "AER 1 0 fatal 0 non-fatal 1 corrected" in my output - I don't know if it's significant. e...@pci0:3:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfb5e, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled bar [1c] = type Memory, range 32, base 0xfb5dc000, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 0025900b775c e...@pci0:4:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfb6e, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xec00, size 32, enabled bar [1c] = type Memory, range 32, base 0xfb6dc000, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 0025900b775d ___ 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: em driver, 82574L chip, and possibly ASPM
On 12/24/2010 5:44 PM, Jan Koum wrote: > hi Ivan and Mike, > > wanted to follow up and see if you found a solid long-term solution to this > bug. we are still seeing this problem in our 8.2 environment with ASPM > already disabled. here is what we have: > > 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: > Hi Jack, Looks like this problem is not completely gone :( I have seen it now on 2 different machines. On the RELENG_7, ASPM was enabled in the BIOS (INTEL DH55TC MB), so I have disabled that for now to see what happens. On the RELENG_8 machine, its been a LOT better since 7.1.8, but again it happened last night during a backup dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.8 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0x34ec class=0x02 dev.em.1.%parent: pci10 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.flow_control: 3 dev.em.1.link_irq: 346 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1209008712 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 231 dev.em.1.queue0.txd_tail: 231 dev.em.1.queue0.tx_irq: 828804317 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 692 dev.em.1.queue0.rxd_tail: 691 dev.em.1.queue0.rx_irq: 1035962009 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 395 dev.em.1.mac_stats.recv_no_buff: 22 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 2374779279 dev.em.1.mac_stats.good_pkts_recvd: 2374778884 dev.em.1.mac_stats.bcast_pkts_recvd: 91866 dev.em.1.mac_stats.mcast_pkts_recvd: 14709 dev.em.1.mac_stats.rx_frames_64: 3694217 dev.em.1.mac_stats.rx_frames_65_127: 42644392 dev.em.1.mac_stats.rx_frames_128_255: 52724116 dev.em.1.mac_stats.rx_frames_256_511: 768263 dev.em.1.mac_stats.rx_frames_512_1023: 28549934 dev.em.1.mac_stats.rx_frames_1024_1522: 2246397962 dev.em.1.mac_stats.good_octets_recvd: 3420561094673 dev.em.1.mac_stats.good_octets_txd: 130129757787 dev.em.1.mac_stats.total_pkts_txd: 1553568635 dev.em.1.mac_stats.good_pkts_txd: 1553568635 dev.em.1.mac_stats.bcast_pkts_txd: 13131 dev.em.1.mac_stats.mcast_pkts_txd: 9 dev.em.1.mac_stats.tx_frames_64: 564243380 dev.em.1.mac_stats.tx_frames_65_127: 864123029 dev.em.1.mac_stats.tx_frames_128_255: 119250324 dev.em.1.mac_stats.tx_frames_256_511: 240369 dev.em.1.mac_stats.tx_frames_512_1023: 554247 dev.em.1.mac_stats.tx_frames_1024_1522: 5157286 dev.em.1.mac_stats.tso_txd: 1216433 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 51 dev.em.1.interrupts.rx_pkt_timer: 0 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 0 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 0 em1: flags=8843 metric 0 mtu 1500 options=219b ether 00:15:17:ed:68:a4 inet xx.yy.13.254 netmask 0xff00 broadcast zz.yy.13.255 inet6 fe80::215:17ff:feed:68a4%em1 prefixlen 64 scopeid 0x3 inet xx.zz.1.1 netmask 0xff00 broadcast xx.zz.1.255 inet6 2607:f3e0:xx prefixlen 64 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active e...@pci0:10:0:0:class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ed68a4 The MB is an INTEL S3420GPX ---Mike ___ freebsd-net@freebsd.org mailing list http://l
Re: PPP and Route Delete
> I've been working on migrating a PPTP server from FreeBSD 7.1 to FreeBSD 8.1. > The server is configured using PopTop (from ports) and PPP (/usr/sbin) > rather than MPD. (Before anybody tells me to use MPD we can't because it > doesn't inject packets into the kernel in the same way and it's not possible > to filter on them correctly) > > Basic PPTP connection works properly. > > The fun happens when I have two simultaneous users. The first one to > DISCONNECT deletes the routes for both of them and all PPTP traffic ceases. Just been working my way through the PPP code - which doesn't actually appear to have changed. However, the netinet/in.c does have some comments in the SVN history about deleting the loopback address, this appears to have been merged in as part of the 8 release cycle (r197231 perhaps) (though I'm not an expert at SVN etc) What should happen when there are multiple interfaces with the same address. When I have two tunnels configured they show up as (eg) tun0: flags=8051 metric 0 mtu 1398 options=8 inet 10.0.5.1 --> 10.0.0.31 netmask 0x Opened by PID 12616 tun1: flags=8051 metric 0 mtu 1398 options=8 inet 10.0.5.1 --> 10.0.0.32 netmask 0x Opened by PID 12630 If the loop back address is 10.0.5.1 and closing one of them deletes the loopback what should happen? Should it delete all routes that refer to 10.0.5.1? Mel ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, 11 Jan 2011, Yamagi Burmeister wrote: Very large and famous (due to very attractive prices) hosting provider Hetzner.de discards FreeBSD support on dedicated servers, because these servers can niot negotiate 100Mbit/DUPLEX when switches' ports are limited to 100Mbit (1Gbit connection costs additional money) only under FreeBSD. Linux works fine. Switches known to be Juniper e3k series. ... I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs just fine. I've never seen this strange negotiation problem myself. But maybe I was just lucky and got working mainboard and nic combinations. So if further information is needed, I'm happy to provide it. A lot of us do. There is a problem with the re(4) setup as well in that if you do not send packets out yourself the port takes a very long time to come up and unblocked. I haven't discussed that with them or tested with an updated HEAD (since end of October). But yes, I am running HEAD on an EQ4 as well. If you have problems and a personal email contact at Hetzner feel free to talk to me. I am "local" (a couple of 100km away in the same country) and a FreeBSD committer and I can probably figure things out with them or properly proxy requests. /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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
Hello, Yamagi. You wrote 11 января 2011 г., 13:30:23: > Hi, > I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs > just fine. I've never seen this strange negotiation problem myself. But > maybe I was just lucky and got working mainboard and nic combinations. > So if further information is needed, I'm happy to provide it. It is known, that problems are in DC 13 and everything wotrks fine in DC 11 and DC 12. I've discussed this problem in local (Russian-speaking) FreeBSD community, and there are several people in DC 13 who HAVE these problems and found different solutions, but all non-technical ones: order gigabit connectivity, or pay for moving servers to other (old) DCs... -- // Black Lion AKA Lev Serebryakov ___ 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: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
On Tue, 11 Jan 2011, Lev Serebryakov wrote: Very large and famous (due to very attractive prices) hosting provider Hetzner.de discards FreeBSD support on dedicated servers, because these servers can niot negotiate 100Mbit/DUPLEX when switches' ports are limited to 100Mbit (1Gbit connection costs additional money) only under FreeBSD. Linux works fine. Switches known to be Juniper e3k series. MoBos of servers are different assortment of MSI MoBos with Realtek (re driver) network-on-board. Symptjms are: NIC can not negotiate/set duplex when switch port is limited to 100Mbit/Duplex. Duplex can not be set even manually via "ifconfig": media: Ethernet 100baseTX (100baseTX ) Is it know problem? Maybe, -CURRENT driver has fix for it? Unfortunately, I can not provide more information, as I don't have server at Hetzner (I'm planning to order one, but due to these problems, I'm not sure now, as I need FreeBSD), and all this information is collected in communication with people who HAVE servers with FreeBSD installed. Hi, I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs just fine. I've never seen this strange negotiation problem myself. But maybe I was just lucky and got working mainboard and nic combinations. So if further information is needed, I'm happy to provide it. Some data: % ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b [snip] nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active $ dmesg re0: port 0xe800-0xe8ff mem 0xfbeff000-0xfbef,0xf6ff-0xf6ff irq 16 at device 0.0 on pci6 re0: Using 1 MSI messages re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 40:61:86:f3:d7:20 re0: [FILTER] Also have a look at the FreeBSD section in the Hetzner Wiki: http://wiki.hetzner.de/index.php/FreeBSD It's in german but Google can translate it :) Ciao, Yamagi -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB ___ 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: PPP and Route Delete
On 11 Jan 2011, at 09:13, Luiz Otavio O Souza wrote: > On Jan 10, 2011, at 2:25 PM, Melissa Jenkins wrote: >> >> I've been working on migrating a PPTP server from FreeBSD 7.1 to FreeBSD >> 8.1. The server is configured using PopTop (from ports) and PPP (/usr/sbin) >> rather than MPD. (Before anybody tells me to use MPD we can't because it >> doesn't inject packets into the kernel in the same way and it's not possible >> to filter on them correctly) >> >> Basic PPTP connection works properly. >> >> The fun happens when I have two simultaneous users. The first one to >> DISCONNECT deletes the routes for both of them and all PPTP traffic ceases. >> >> I believe this is because of the third RTM_DELETE message in the route >> monitor output below (From FreeBSD 8.1): > > > I believe it's the second call... but probably doesn't matter... Yes - I must have switched programming languages and ended up starting at 1 :( > > How are you setting the IP address for vpn connections (radius?) ? > I've got them configured in the third column in the secret file: eg: ... melissa dummypw 10.0.0.31 john dummypw 10.0.0.32 > I'm also using poptop with ppp without any problem, here is my ppp.conf (look > at differences on 'set ifaddr'): > > default: > set log Phase Chat LCP IPCP CCP tun command Warning Error > ident user-ppp VERSION (built COMPILATIONDATE) > > pptp: > set ifaddr 10.10.0.1 10.10.3.100-10.10.3.104 255.255.255.255 > [snip] > Some details: > > 10.10.0.1 is the internal IP on the pptp server; > 10.10.3.100-10.10.3.104 is my range of IPs used for vpn purposes (i'm using > 10.10.0.0/22 as internal network). I've just tried it configured as set ifaddr 10.0.5.1 HISADDR 255.255.255.255 It still sends the route delete: got message of size 192 on Mon Jan 10 23:35:03 2011 RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default 10.0.5.1 default with set ifaddr 10.0.5.1 10.0.0.1-10.0.0.255 255.255.255.255 got message of size 192 on Mon Jan 10 23:37:02 2011 RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default 10.0.5.1 default :( Going to spend some time looking at the PPP code and see if I can figure out what triggers it. Mel___ 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"
Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)
Hello, Freebsd-net. Very large and famous (due to very attractive prices) hosting provider Hetzner.de discards FreeBSD support on dedicated servers, because these servers can niot negotiate 100Mbit/DUPLEX when switches' ports are limited to 100Mbit (1Gbit connection costs additional money) only under FreeBSD. Linux works fine. Switches known to be Juniper e3k series. MoBos of servers are different assortment of MSI MoBos with Realtek (re driver) network-on-board. Symptjms are: NIC can not negotiate/set duplex when switch port is limited to 100Mbit/Duplex. Duplex can not be set even manually via "ifconfig": media: Ethernet 100baseTX (100baseTX ) Is it know problem? Maybe, -CURRENT driver has fix for it? Unfortunately, I can not provide more information, as I don't have server at Hetzner (I'm planning to order one, but due to these problems, I'm not sure now, as I need FreeBSD), and all this information is collected in communication with people who HAVE servers with FreeBSD installed. Again, I know, that Realtek NICs are crap, but "everybody says" that Linux doesn't have THIS problem with THESE boards and switches. -- // Black Lion AKA Lev Serebryakov ___ 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: PPP and Route Delete
On Jan 10, 2011, at 2:25 PM, Melissa Jenkins wrote: > > I've been working on migrating a PPTP server from FreeBSD 7.1 to FreeBSD 8.1. > The server is configured using PopTop (from ports) and PPP (/usr/sbin) > rather than MPD. (Before anybody tells me to use MPD we can't because it > doesn't inject packets into the kernel in the same way and it's not possible > to filter on them correctly) > > Basic PPTP connection works properly. > > The fun happens when I have two simultaneous users. The first one to > DISCONNECT deletes the routes for both of them and all PPTP traffic ceases. > > I believe this is because of the third RTM_DELETE message in the route > monitor output below (From FreeBSD 8.1): I believe it's the second call... but probably doesn't matter... > > got message of size 304 on Mon Jan 10 15:48:40 2011 > RTM_CHANGE: Change Metrics or flags: len 304, pid: 7871, seq 3, errno 0, > flags: > locks: inits: > sockaddrs: > 10.0.0.31 tun0 (255) tun0 10.0.5.1 > > got message of size 232 on Mon Jan 10 15:48:40 2011 > RTM_DELETE: Delete Route: len 232, pid: 7871, seq 4, errno 0, > flags: > locks: inits: > sockaddrs: > 10.0.0.31 tun0 (255) > > got message of size 168 on Mon Jan 10 15:48:40 2011 > RTM_IFINFO: iface status change: len 168, if# 11, link: up, > flags: > > got message of size 192 on Mon Jan 10 15:48:40 2011 > RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > default 10.0.5.1 default > > got message of size 116 on Mon Jan 10 15:48:40 2011 > RTM_DELADDR: address being removed from iface: len 116, metric 0, flags: > sockaddrs: > 255.255.255.255 tun0 10.0.5.1 10.0.0.31 > > On FreeBSD 7.1 the output is as follows: > > got message of size 232 on Mon Jan 10 16:18:11 2011 > RTM_CHANGE: Change Metrics or flags: len 232, pid: 43773, seq 3, errno 0, > flags: > locks: inits: > sockaddrs: > 10.0.0.31 tun14 (255) > > got message of size 232 on Mon Jan 10 16:18:11 2011 > RTM_DELETE: Delete Route: len 232, pid: 43773, seq 4, errno 0, > flags: > locks: inits: > sockaddrs: > 10.0.0.31 tun14 (255) > > got message of size 168 on Mon Jan 10 16:18:11 2011 > RTM_IFINFO: iface status change: len 168, if# 23, link: unknown, > flags: > > > There are quite a few additional messages on connect as well but I don't > believe they are impacting on my issue. Looking in usr.sbin/ppp/route.c I > can't see any changes that would obviously impact on this :( > > My ppp config for both 7.1 & 8.x is as follows: > > default: > set log Chat LCP IPCP CCP tun command > > pptp: > set timeout 0 > set login > set ifaddr 10.0.5.1/24 HISADDR 255.255.255.255 > disable deflate pred1 > deny deflate pred1 > enable MPPE > accept MPPE > enable chap81 > set mppe 128 stateless > > I have also confirmed the same behaviour on 8.0 > > Any ideas?? How are you setting the IP address for vpn connections (radius?) ? I'm also using poptop with ppp without any problem, here is my ppp.conf (look at differences on 'set ifaddr'): default: set log Phase Chat LCP IPCP CCP tun command Warning Error ident user-ppp VERSION (built COMPILATIONDATE) pptp: set ifaddr 10.10.0.1 10.10.3.100-10.10.3.104 255.255.255.255 set timeout 0 enable chap81 disable deflate pred1 deny deflate pred1 enable proxy accept dns set dns 10.10.0.1 set nbns 10.10.0.11 set mtu max 1490 set mru 1490 disable echo set echoperiod 5 disable ipv6cp set mppe 128 stateless Some details: 10.10.0.1 is the internal IP on the pptp server; 10.10.3.100-10.10.3.104 is my range of IPs used for vpn purposes (i'm using 10.10.0.0/22 as internal network). Regards, Luiz___ 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"
