Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4)
The following reply was made to PR kern/126742; it has been noted by GNATS.
From: Alex <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4)
Date: Sat, 23 Aug 2008 02:13:27 GMT
>Submitter-Id: current-users
>Originator: Alex
>Organization:
>Confidential: no
>Synopsis: Re: kern/126742: [panic] kernel panic when sending file via
>ng_ubt(4)
>Severity: serious
>Priority: medium
>Category: kern
>Class:sw-bug
>Release: 7-STABLE
>Environment: FreeBSD moshnroll 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Aug 19
>21:20:04 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARUNDEL i386
>Description:
is there a reason that the problem report database ignores any text if there's
a line with a single dot (".") and nothing else in it?
i know that in 'mail' that's the way to end your text, but as you can see it's
not very useful in the case of this problem report.
cheers.
>How-To-Repeat:
>Fix:
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Wireless and Broadcast packets problem
Hi Guys I am having a problem with my wireless network. The Issue is that clients connected to the wireless LAN cannot _see_ other clients. My understanding of 802.11 was that clients could talk to other clients, except all traffic would go via the access point and that the AP would forward on the packets. This also ensures that encryption works as expected as well as other RF issues. One thing that I can see is going wrong is that clients on the Wireless Lan sending Broadcast packets, but they are not being forwarded by the AP to anyone else... Wireless clients also cannot ping each other (mainly because their ARP requests are not being answered) Below is a simplified system diagram. AdriansPC AlbertAP \|/ - 192.168.123/24 | ||--LAN--bge0-||---| ral0 (192.168.124/24) ||||--tun0--->PPPoE(bge0) WindowsFreeBSD Sneaky\|/ -| ||---| 192.168.124.2 (Static IP address) || ral0 FreeBSD Laptop\|/ -| ||---| 192.168.124.150 (DHCP) || Windows When running TCPDump on AlbertAP I can see plenty of wireless traffic going around the place. Wireless Clients are able to connect and have their session is encrypted with WPA. This all seems to work, wireless clients are able to browse the net. (Those that can get an IP address anyway, which happens to be the windows machines) *Problem* I have run tcpdump on both AlbertAP and Sneaky and seem some interesting omissions. When I ping Sneaky from Laptop I see on Albert the ARP request come out from Laptop asking for Sneaky's MAC address. AlbertAP> tcpdump -i ral0 10:27:51.979664 arp who-has 192.168.124.2 tell 192.168.124.150 10:27:51.979684 arp who-has 192.168.124.2 tell 192.168.124.150 But on Sneaky I cannot see these packets comming in... All I get is random EAP traffic Sneaky> tcpdump -i ral0 10:30:32.987961 EAP code=2 id=3 length=123 10:30:32.988383 EAP code=1 id=3 length=95 10:30:32.990557 EAP code=2 id=3 length=135 10:30:32.991548 EAP code=1 id=3 length=95 However if a Wired client like AdriansPC tries to ping Laptop then things work. Albert knows the MAC address of the Wireless client to send the ping packet to and so just sends it off. *Problem* The other thing I see alot of is netbios broadcast traffic coming from the Laptop on the wireless. Albert can see all this traffic coming in, but none of it gets forwarded to Sneaky, (nothing about netbios from a tcpdump on sneaky). The same can be said for a particular client doing DHCP/BOOTP. On AlbertAP, I see the request come in and see the response go out (the response goes to 255.255.255.255) but I do not see this on sneaky (I should right, its a broadcast address). Oh and I don't think this client is actually getting a response as I can't do much with it(ie ping). (Its a wireless print server) Interestingly enough DHCP does seem to work to Laptop. I believe that this is because windows is doing DHCP, where as my print server is doing BOOTP. *It does work* Just so you believe me that normal traffic does get around, here is a ping from sneaky to albert. Sneaky> tcpdump -i ral0 10:36:11.243678 arp who-has 192.168.124.1 tell 192.168.124.2 10:36:11.244634 arp reply 192.168.124.1 is-at 00:1a:ee:00:d5:c0 (oui Unknown) 10:36:11.244693 IP 192.168.124.2 > 192.168.124.1: ICMP echo request, id 18949, seq 0, length 64 10:36:11.251920 IP 192.168.124.1 > 192.168.124.2: ICMP echo reply, id 18949, seq 0, length 64 AlbertAP> tcpdump -i ral0 10:36:11.241001 arp who-has 192.168.124.1 tell 192.168.124.2 10:36:11.241017 arp who-has 192.168.124.1 tell 192.168.124.2 10:36:11.241042 arp reply 192.168.124.1 is-at 00:1a:ee:00:d5:c0 (oui Unknown) 10:36:11.248582 IP 192.168.124.2 > 192.168.124.1: ICMP echo request, id 18949, seq 0, length 64 10:36:11.248600 IP 192.168.124.1 > 192.168.124.2: ICMP echo reply, id 18949, seq 0, length 64 *Discussion Point* I find it interesting that sneaky asks for 192.168.124.1's MAC address with an ARP request, but albert got two of them... *System Details* Things are basically setup as detailed in the Handbook, with the wireless LAN on a different Subnet to the wired one. I have also had a go at bridging the two interfaces but ran into trouble so didn't spend long there. I expect I would have the same issues. AlbertAP> uname -a FreeBSD albertAP 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #2: Mon Jul 14 09:00:17 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AdriansKernel i386 AlbertAP> ifconfig bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:85:b3:a2:7e inet 192.168.123.1 netmask 0xff00 broadcast 192.168.123.255 media: Ethernet autoselect (100baseTX ) status: active ral0: flags=8943 metric 0 mtu 2290 ether 00:1a:ee:00:d5:c0 inet 192.168.124.1 netmask 0xff00 broadcast 192
Re: ndis0 no link on 6.3-RELEASE
Hi everyone. Sorry to bump such an old post, but I have figured out a 'hack' to get this driver to work, and figured I'd post here, in case it may help someone else. Previously, I said the following, about a Broadcom 4318 chipset on a Dell Inspiron b120: "Upon 'kldunload bcmwl5.ko; kldload bcmwl5.ko', my ndis0 card looses all WPA capabilities." The fix is as follows, as I have been unable to find anything relevant regarding netif, dhclient, wpa_supplicant or ndis: Step 1: Create /etc/rc.local, with '/sbin/kldload /boot/modules/bcmwl5_sys.ko' Step 2: Edit /etc/wpa_supplicant.conf as needed Step 3: Echo 'ifconfig_ndis0="WPA DHCP"' to /etc/rc.conf Outcome: System boots, loading netif, dhclient, and wpa_supplicant. Next, after the other three are running, the rc.local script loads the ndis0 driver. On my system (and surrounding networks) my system tries to authenticate against any available network, but then finally reads wpa_supplicant.conf, and uses my network. As I said, sorry to bump an old thread, but hopefully this will help someone else, regardless of how crude of a hack it is. Regards, -- Glen Barber ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4)
The following reply was made to PR kern/126742; it has been noted by GNATS. From: Alex <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Date: Fri, 22 Aug 2008 22:27:39 GMT >Submitter-Id: current-users >Originator: Alex >Organization: >Confidential: no >Synopsis: Re: kern/126742: [panic] kernel panic when sending file via >ng_ubt(4) >Severity: serious >Priority: medium >Category: kern >Class:sw-bug >Release: 7-STABLE >Environment: FreeBSD moshnroll 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Aug 19 >21:20:04 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARUNDEL i386 >Description: ok. one last try. i'll simply attach the dmesg output as a file. >How-To-Repeat: >Fix: Patch attached with submission follows: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARUNDEL WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (2997.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x2010 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2086535168 (1989 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7fde (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc07f mem 0xf600-0xf6ff,0xe000-0xefff,0xf400-0xf5ff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] uhci0: port 0xe200-0xe21f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe000-0xe01f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe100-0xe11f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xf8205000-0xf82053ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcm0: mem 0xf820-0xf8203fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 atapci0: port 0xd000-0xd007,0xd100-0xd103,0xd200-0xd207,0xd300-0xd303,0xd400-0xd40f mem 0xf800-0xf8001fff irq 19 at device 0.0 on pci3 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 uhci3: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xf8204000-0xf82043ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at dev
Re: Small patch to multicast code...
At Fri, 22 Aug 2008 22:43:39 +0100, Bruce M. Simpson wrote: > > [EMAIL PROTECTED] wrote: > > Somehow the data that the device needs to do the proper checksum > > offload is getting trashed here. Now, since it's clear we need a > > writable packet structure so that we don't trash the original, I'm > > wondering if the m_pullup() will be sufficient. > > > > If it's serious enough to break UDP checksumming on the wire, perhaps we > should just swallow the mbuf allocator heap churn and do the m_dup() for > now, but slap in a big comment about why it's there. I think if none of us finds a better way before early next week that's what I'll do so that this at least works in 7.1. Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
[EMAIL PROTECTED] wrote: Somehow the data that the device needs to do the proper checksum offload is getting trashed here. Now, since it's clear we need a writable packet structure so that we don't trash the original, I'm wondering if the m_pullup() will be sufficient. If it's serious enough to break UDP checksumming on the wire, perhaps we should just swallow the mbuf allocator heap churn and do the m_dup() for now, but slap in a big comment about why it's there. BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
At Fri, 22 Aug 2008 19:43:03 +0100,
Bruce M. Simpson wrote:
>
> We end up calling if_simloop() from a few "interesting" places, in
> particular the kernel PIM packet handler.
>
> In this particular case we're going to take a full mbuf chain copy every
> time we send a packet which needs to be looped back to userland.
Right, I know the penalty.
> It's been a while since I've done any in-depth FreeBSD work other
> than hacking on the IGMPv3 snap, and my time is largely tied up with
> other work these days, sadly.
>
> It doesn't seem right to my mind that we need to make a full copy of
> an mbuf chain with m_dup() to workaround this kind of problem.
>
> Whilst it may suffice for a band-aid workaround, we may see mbuf
> pool fragmentation as packet rates go up.
>
> However we are now in a "new world order" where mbuf chains may be
> very tied to the device where they've originated or to where they're
> going. It isn't clear to me where this kind of intrusion is
> happening.
>
> In the case of ip_mloopback(), somehow we are stomping on a
> read-only copy of an mbuf chain. The use of m_copy() with m_pullup()
> there is fine according to the documented uses of mbuf(9), although
> as Luigi pointed out, most likely we need to look at the upper-layer
> protocol too, e.g. where UDP checksums are also being offloaded.
>
> Some of the code in the IGMPv3 branch actually reworks how loopback
> happens i.e. the preference is not to loop back wherever possible
> because of the locking implications. Check the bms_netdev branch
> history for more info.
Well, what I suspect is the problem are these bits:
udp_output():
/*
* Set up checksum and output datagram.
*/
if (udp_cksum) {
if (inp->inp_flags & INP_ONESBCAST)
faddr.s_addr = INADDR_BROADCAST;
ui->ui_sum = in_pseudo(ui->ui_src.s_addr, faddr.s_addr,
htons((u_short)len + sizeof(struct udphdr) + IPPROTO_UDP));
m->m_pkthdr.csum_flags = CSUM_UDP;
m->m_pkthdr.csum_data = offsetof(struct udphdr, uh_sum);
} else
ip_mloopback():
copym = m_copy(m, 0, M_COPYALL);
if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen))
copym = m_pullup(copym, hlen);
if (copym != NULL) {
/* If needed, compute the checksum and mark it as valid. */
if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
in_delayed_cksum(copym);
copym->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA;
copym->m_pkthdr.csum_flags |=
CSUM_DATA_VALID | CSUM_PSEUDO_HDR;
copym->m_pkthdr.csum_data = 0x;
}
and:
in_delayed_cksum(struct mbuf *m)
{
struct ip *ip;
u_short csum, offset;
ip = mtod(m, struct ip *);
offset = ip->ip_hl << 2 ;
csum = in_cksum_skip(m, ip->ip_len, offset);
if (m->m_pkthdr.csum_flags & CSUM_UDP && csum == 0)
csum = 0x;
offset += m->m_pkthdr.csum_data;/* checksum offset */
Somehow the data that the device needs to do the proper checksum
offload is getting trashed here. Now, since it's clear we need a
writable packet structure so that we don't trash the original, I'm
wondering if the m_pullup() will be sufficient.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
At Fri, 22 Aug 2008 21:42:00 +0200, Luigi Rizzo wrote: > > On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: > > [EMAIL PROTECTED] wrote: > > >I gather you mean that a fast link on which also we're looping back > > >the packet will be an issue? Since this packet is only going into the > > >simloop() routine. > > > > > > > We end up calling if_simloop() from a few "interesting" places, in > > particular the kernel PIM packet handler. > > > > In this particular case we're going to take a full mbuf chain copy every > > time we send a packet which needs to be looped back to userland. > ... > > In the case of ip_mloopback(), somehow we are stomping on a read-only > > copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine > > according to the documented uses of mbuf(9), although as Luigi pointed > > out, most likely we need to look at the upper-layer protocol too, e.g. > > where UDP checksums are also being offloaded. > > in fact, george, if you have an easy way to reproduce the error, > could you see if reverting your change and instead adding > sizeof(struct udphdr) to the length argument in the call to m_pullup() > fixes the problem ? I don't have sample code I can give but it's simple to set up and test. On machine A set up a sender and a listener for the same multicast group/port. On machine B set up a listener. Send from A with the listener on. B should see nothing and its "bad checksums" counter should increase. Turn off listener on A. Send again, B should get the packet. If you listen to the traffic with tcpdump on a 3rd machine you'll see that the checksum is constant, even if the data in the packet, like the ports, is not. Your ethernet cards have to have hardware checksum offloading. I'm using em/igb in 7-STABLE. Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange TCP issue on RELENG_7
At 04:01 PM 8/22/2008, Bjoern A. Zeeb wrote: On Fri, 22 Aug 2008, Mike Tancsa wrote: At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: can you make sure you have this? http://svn.freebsd.org/changeset/base/181596 Hi, I do. I am running a GENERIC kernel but with inet6 disabled from yesterday 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 and with the patch below as TOE seems to be broken for my workload okay. Does netstat -s -p tcp should any obvious error counters raising? I just try to get the easy things sorted out before anyone starts to debug more TCP... Not sure, what is obvious :) This host is part of the primary MX list for a lot of inbound traffic, so there will be all sorts of hosts using all sorts of stacks connecting to it. netstat -ni shows no errors as do the stats from the em driver (below) tcp: 26989994 packets sent 17034559 data packets (84842431 bytes) 101073 data packets (20893246 bytes) retransmitted 4586 data packets unnecessarily retransmitted 2 resends initiated by MTU discovery 6523153 ack-only packets (333850 delayed) 0 URG only packets 0 window probe packets 1016646 window update packets 2314525 control packets 27848527 packets received 15078177 acks (for 78677787 bytes) 830948 duplicate acks 4689 acks for unsent data 11374257 packets (4127132455 bytes) received in-sequence 40287 completely duplicate packets (30901526 bytes) 921 old duplicate packets 352 packets with some dup. data (179712 bytes duped) 225759 out-of-order packets (276463593 bytes) 8 packets (0 bytes) of data after window 0 window probes 710635 window update packets 298525 packets received after close 849 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 5855 discarded due to memory problems 855019 connection requests 1091001 connection accepts 0 bad connection attempts 10943 listen queue overflows 79448 ignored RSTs in the windows 1944666 connections established (including accepts) 2088626 connections closed (including 516007 drops) 840374 connections updated cached RTT on close 842332 connections updated cached RTT variance on close 60049 connections updated cached ssthresh on close 1201 embryonic connections dropped 14026440 segments updated rtt (of 12656642 attempts) 157370 retransmit timeouts 7412 connections dropped by rexmit timeout 1 persist timeout 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 886 keepalive timeouts 13 keepalive probes sent 873 connections dropped by keepalive 110658 correct ACK header predictions 7810293 correct data packet header predictions 1114950 syncache entries added 63212 retransmitted 35592 dupsyn 77 dropped 1091001 completed 0 bucket overflow 0 cache overflow 4908 reset 8260 stale 10943 aborted 0 badack 174 unreach 0 zone failures 1115027 cookies sent 361 cookies received 2843 SACK recovery episodes 2620 segment rexmits in SACK recovery episodes 3722090 byte rexmits in SACK recovery episodes 35491 SACK options (SACK blocks) received 162860 SACK options (SACK blocks) sent 0 SACK scoreboard overflow Aug 22 16:13:28 smtp2 kernel: em0: Excessive collisions = 0 Aug 22 16:13:28 smtp2 kernel: em0: Sequence errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Defer count = 0 Aug 22 16:13:28 smtp2 kernel: em0: Missed Packets = 0 Aug 22 16:13:28 smtp2 kernel: em0: Receive No Buffers = 0 Aug 22 16:13:28 smtp2 kernel: em0: Receive Length Errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Receive errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Crc errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Alignment errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Collision/Carrier extension errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: RX overruns = 0 Aug 22 16:13:28 smtp2 kernel: em0: watchdog timeouts = 0 Aug 22 16:13:28 smtp2 kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Aug 22 16:13:28 smtp2 kernel: em0: XON Rcvd = 0 Aug 22 16:13:28 smtp2 kernel: em0: XON Xmtd = 0 Aug 22 16:13:28 smtp2 kernel: em0: XOFF Rcvd = 0 Aug 22 16:13:28 smtp2 kernel: em0: XOFF Xmtd = 0 Aug 22 16:13:28 smtp2 kerne
Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4)
Old Synopsis: kernel panic when sending file via ng_ubt New Synopsis: [panic] kernel panic when sending file via ng_ubt(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 22 20:02:51 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126742 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange TCP issue on RELENG_7
On Fri, 22 Aug 2008, Mike Tancsa wrote: At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: can you make sure you have this? http://svn.freebsd.org/changeset/base/181596 Hi, I do. I am running a GENERIC kernel but with inet6 disabled from yesterday 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 and with the patch below as TOE seems to be broken for my workload okay. Does netstat -s -p tcp should any obvious error counters raising? I just try to get the easy things sorted out before anyone starts to debug more TCP... /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: > [EMAIL PROTECTED] wrote: > >I gather you mean that a fast link on which also we're looping back > >the packet will be an issue? Since this packet is only going into the > >simloop() routine. > > > > We end up calling if_simloop() from a few "interesting" places, in > particular the kernel PIM packet handler. > > In this particular case we're going to take a full mbuf chain copy every > time we send a packet which needs to be looped back to userland. ... > In the case of ip_mloopback(), somehow we are stomping on a read-only > copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine > according to the documented uses of mbuf(9), although as Luigi pointed > out, most likely we need to look at the upper-layer protocol too, e.g. > where UDP checksums are also being offloaded. in fact, george, if you have an easy way to reproduce the error, could you see if reverting your change and instead adding sizeof(struct udphdr) to the length argument in the call to m_pullup() fixes the problem ? cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange TCP issue on RELENG_7
At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: can you make sure you have this? http://svn.freebsd.org/changeset/base/181596 Hi, I do. I am running a GENERIC kernel but with inet6 disabled from yesterday 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 and with the patch below as TOE seems to be broken for my workload # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable --- sys/netinet/tcp_offload.c 2008-08-01 13:47:27.0 -0400 +++ sys/netinet/tcp_offload.c.disable 2008-08-22 15:16:50.0 -0400 @@ -58,6 +58,8 @@ struct rtentry *rt; int error; + return (EINVAL); + /* * Look up the route used for the connection to * determine if it uses an interface capable of I can try changing to ipfw and see if that makes a difference ? But the RST doesnt sound like a pf issue no ? I would have thought it would just blackhole the packet. ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange TCP issue on RELENG_7
On Fri, 22 Aug 2008, Mike Tancsa wrote:
On one of our sendmail boxes that we are running RELENG_7, we have noticed an
odd issue triggered or noticed by our monitoring system (bigbrother in this
case). The seems to have been happening ever since we installed it, so its
not a recent commit issue.
Every 5 min, one of our monitoring stations connects to the box on port 25
The connection process is pretty simple. It connects and sends a QUIT and if
that works, all is "ok".
Here is a normal exchange
...
But, perhaps twice a day, or once every 2 days, I will see an RST from the
host being monitored for some reason?!
It looks like
...
I dont ever see this on RELENG_6, only on RELENG_7. It doesnt seem to be load
related as I will see it at various times of the day both busy and quiet and
sendmail is not complaining about too many connections which it will when
there are.
192.168.1.2 is the monitoring host running bb and 192.168.1.9 is the smtp
server being tested. I do have pf on the box, but pf isnt set to send RSTs
and I think if there is a state mismatch, it will just drop the packet and
not send the RST. I have tried with and without scrub but no obvious
difference
Rules are simple
set skip on lo0
scrub in all
block in log on {em0,em1}
pass in on {em0,em1} proto {tcp,udp} from
pass in on {em0,em1,lo0} proto tcp from any to any port {25,53,587}
pass in on {em0,em1,lo0} proto udp from any to any port {53}
pass in on {em0,em1} proto icmp from any to any
pass out on {em0,em1} proto {icmp,tcp,udp} from any to any
can you make sure you have this?
http://svn.freebsd.org/changeset/base/181596
--
Bjoern A. Zeeb Stop bit received. Insert coin for new game.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
[EMAIL PROTECTED] wrote: I gather you mean that a fast link on which also we're looping back the packet will be an issue? Since this packet is only going into the simloop() routine. We end up calling if_simloop() from a few "interesting" places, in particular the kernel PIM packet handler. In this particular case we're going to take a full mbuf chain copy every time we send a packet which needs to be looped back to userland. I was actually hoping, as the person who last hacked this code, that you might have a suggestion as to a "right" fix. It's been a while since I've done any in-depth FreeBSD work other than hacking on the IGMPv3 snap, and my time is largely tied up with other work these days, sadly. It doesn't seem right to my mind that we need to make a full copy of an mbuf chain with m_dup() to workaround this kind of problem. Whilst it may suffice for a band-aid workaround, we may see mbuf pool fragmentation as packet rates go up. However we are now in a "new world order" where mbuf chains may be very tied to the device where they've originated or to where they're going. It isn't clear to me where this kind of intrusion is happening. In the case of ip_mloopback(), somehow we are stomping on a read-only copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine according to the documented uses of mbuf(9), although as Luigi pointed out, most likely we need to look at the upper-layer protocol too, e.g. where UDP checksums are also being offloaded. Some of the code in the IGMPv3 branch actually reworks how loopback happens i.e. the preference is not to loop back wherever possible because of the locking implications. Check the bms_netdev branch history for more info. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
At Fri, 22 Aug 2008 03:27:11 +0100, Bruce M. Simpson wrote: > > [EMAIL PROTECTED] wrote: > >> The only thing i can think of is that it's the UDP checksum, > >> residing beyond hlen, which is overwritten somewhere in the > >> call to if_simloop -- in which case perhaps a better fix is > >> to m_pullup() the udp header as well ? > >> > > > > It is the checksum that gets trashed, yes. > > ... > > The m_*() routines actually have reasonable comments, it just seems > > the wrong one was used here. > > > > Actually, m_copy() has been legacy for some time now -- see comments. > > I'd be concerned that the change to m_dup() (which makes a full mbuf > chain copy) rather than m_copym() (which bumps refcounts) is going to > eat into the mbuf clusters on fast links, though it's an easy band-aid > for the problem. I gather you mean that a fast link on which also we're looping back the packet will be an issue? Since this packet is only going into the simloop() routine. > I agree with Luigi that some of the API contract for mbuf(9) doesn't > hold any more now that we have TSO and other offload. I was actually hoping, as the person who last hacked this code, that you might have a suggestion as to a "right" fix. Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
strange TCP issue on RELENG_7
On one of our sendmail boxes that we are running RELENG_7, we have
noticed an odd issue triggered or noticed by our monitoring system
(bigbrother in this case). The seems to have been happening ever
since we installed it, so its not a recent commit issue.
Every 5 min, one of our monitoring stations connects to the box on port 25
The connection process is pretty simple. It connects and sends a QUIT
and if that works, all is "ok".
Here is a normal exchange
17:44:27.966100 IP 192.168.1.2.59586 > 192.168.1.9.25: S
1590561033:1590561033(0) win 65535
stamp 603180718 0>
17:44:27.966119 IP 192.168.1.9.25 > 192.168.1.2.59586: S
2644498016:2644498016(0) ack 1590561034 win 65535
e 3,sackOK,timestamp 1701504477 603180718>
17:44:27.966649 IP 192.168.1.2.59586 > 192.168.1.9.25: . ack 1 win
8326
17:44:27.94 IP 192.168.1.2.59586 > 192.168.1.9.25: P 1:12(11) ack
1 win 8326
17:44:27.969087 IP 192.168.1.9.25 > 192.168.1.2.59586: P 1:186(185)
ack 12 win 8326
17:44:27.969119 IP 192.168.1.9.25 > 192.168.1.2.59586: F 186:186(0)
ack 12 win 8326
17:44:27.969642 IP 192.168.1.2.59586 > 192.168.1.9.25: . ack 187 win
8326
17:44:27.969657 IP 192.168.1.2.59586 > 192.168.1.9.25: F 12:12(0) ack
187 win 8326
17:44:27.969668 IP 192.168.1.9.25 > 192.168.1.2.59586: . ack 13 win
8325
But, perhaps twice a day, or once every 2 days, I will see an RST
from the host being monitored for some reason?!
It looks like
17:49:27.496803 IP (tos 0x0, ttl 64, id 8521, offset 0, flags [DF],
proto TCP (6), length 60) 199.212.134.2.65013 > 199.212.134.9.25: S,
cksum 0xabde (correct), 2204170858:2204170858(0) win
65535
17:49:27.496829 IP (tos 0x0, ttl 64, id 42946, offset 0, flags [DF],
proto TCP (6), length 60) 199.212.134.9.25 > 199.212.134.2.65013: S,
cksum 0xfe09 (correct), 3523370477:3523370477(0) ack
2204170859 win 65535 625760391 603480222>
17:49:27.497260 IP (tos 0x0, ttl 64, id 8522, offset 0, flags [DF],
proto TCP (6), length 52) 199.212.134.2.65013 > 199.212.134.9.25: .,
cksum 0x0c4c (correct), 1:1(0) ack 1 win 8326
p,timestamp 603480222 625760391>
17:49:27.497268 IP (tos 0x0, ttl 64, id 42948, offset 0, flags [DF],
proto TCP (6), length 40) 199.212.134.9.25 > 199.212.134.2.65013: R,
cksum 0xe62b (correct), 3523370478:3523370478(0) win
0
17:49:27.497270 IP (tos 0x0, ttl 64, id 8523, offset 0, flags [DF],
proto TCP (6), length 63) 199.212.134.2.65013 > 199.212.134.9.25: P,
cksum 0xb803 (correct), 1:12(11) ack 1 win 8326
nop,timestamp 603480222 625760391>
17:49:27.497277 IP (tos 0x0, ttl 64, id 42949, offset 0, flags [DF],
proto TCP (6), length 40) 199.212.134.9.25 > 199.212.134.2.65013: R,
cksum 0xe62b (correct), 3523370478:3523370478(0) win
0
17:49:34.690828 IP (tos 0x0, ttl 64, id 45325, offset 0, flags [DF],
proto TCP (6), length 60) 199.212.134.9.65077 > 199.212.134.2.25: S,
cksum 0x3e26 (correct), 2116235846:2116235846(0) win
65535
I dont ever see this on RELENG_6, only on RELENG_7. It doesnt seem to
be load related as I will see it at various times of the day both
busy and quiet and sendmail is not complaining about too many
connections which it will when there are.
192.168.1.2 is the monitoring host running bb and 192.168.1.9 is the
smtp server being tested. I do have pf on the box, but pf isnt set to
send RSTs and I think if there is a state mismatch, it will just drop
the packet and not send the RST. I have tried with and without scrub
but no obvious difference
Rules are simple
set skip on lo0
scrub in all
block in log on {em0,em1}
pass in on {em0,em1} proto {tcp,udp} from
pass in on {em0,em1,lo0} proto tcp from any to any port {25,53,587}
pass in on {em0,em1,lo0} proto udp from any to any port {53}
pass in on {em0,em1} proto icmp from any to any
pass out on {em0,em1} proto {icmp,tcp,udp} from any to any
Mike Tancsa, tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
Luigi Rizzo wrote: On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote: [EMAIL PROTECTED] wrote: The only thing i can think of is that it's the UDP checksum, residing beyond hlen, which is overwritten somewhere in the call to if_simloop -- in which case perhaps a better fix is to m_pullup() the udp header as well ? It is the checksum that gets trashed, yes. ... The m_*() routines actually have reasonable comments, it just seems the wrong one was used here. Actually, m_copy() has been legacy for some time now -- see comments. The API is undocumented, but in this specific function the reason for using one rather than the other is undocumented. Especially, if you use m_dup() then the call to m_pullup should be unnecessary. That's why I suggested to explain clearly what is wrong in the original code, so even if now we only apply a temporary bandaid (for lack of time, etc.) hopefully later this can be reverted to something more efficient such as pulling up the UDP header as well. I agree that doing the deep copy is just papering over a bigger problem. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bug in unix sockets garbage collector
On servers where used unix sockets, sometimes thread taskq start to eat 100% CPU: http://docs.FreeBSD.org/cgi/mid.cgi?474EFC5C.9060508 Addition info about this problem - when this occurs sysctl net.local.inflight show negative number. % sysctl net.local.inflight net.local.inflight: -3 And this condition become always true: if (local_unp_rights) taskqueue_enqueue(taskqueue_thread, &unp_gc_task); It seems, that unp_rights decremented more often than incremented, or some race exist. -- Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kernel Panic in SCTP
Hello. We've recently written an extensive software system that uses SCTP as a critical component. We've started to run into an issue where the box kenel panics after throwing an error message from sctp_timer.c that says "Our list is out of order? Out of order list". Can anyone here shed light on what's going on, or give us a clue how to debug this? http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 Joe Mays ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote: > [EMAIL PROTECTED] wrote: > >>The only thing i can think of is that it's the UDP checksum, > >>residing beyond hlen, which is overwritten somewhere in the > >>call to if_simloop -- in which case perhaps a better fix is > >>to m_pullup() the udp header as well ? > >> > > > >It is the checksum that gets trashed, yes. > >... > >The m_*() routines actually have reasonable comments, it just seems > >the wrong one was used here. > > > > Actually, m_copy() has been legacy for some time now -- see comments. The API is undocumented, but in this specific function the reason for using one rather than the other is undocumented. Especially, if you use m_dup() then the call to m_pullup should be unnecessary. That's why I suggested to explain clearly what is wrong in the original code, so even if now we only apply a temporary bandaid (for lack of time, etc.) hopefully later this can be reverted to something more efficient such as pulling up the UDP header as well. cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to make two vlans on one interface working with dhclient
Yes, i applied the modifications at the level of dhclient.conf
2008/8/21 Frank Helbert <[EMAIL PROTECTED]>
> Have you tried?
>
> interface "vlan0" {
> #My options
> }
> interface "vlan1" {
> #My options
> }
>
> Thats the way you identify your vlan nics...
>
> Frank
>
> On Thu, Aug 21, 2008 at 4:03 PM, Popof Popof <[EMAIL PROTECTED]>
> wrote:
> > Here is the output from my ifconfig (I rename rl0.100 and rl0.2101 in
> vlan0
> > and vlan1, the RJ45 wire is disconected because i need internet in order
> to
> > send this message :p ):
> >
> > rl0: flags=8843 mtu 1500
> > options=8
> > inet6 fe80::2e0:4dff:fe30:80e1%rl0 prefixlen 64 scopeid 0x1
> > ether 00:e0:4d:30:80:e1
> > media: Ethernet autoselect (none)
> > status: no carrier
> > lo0: flags=8049 mtu 16384
> > inet6 ::1 prefixlen 128
> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> > inet 127.0.0.1 netmask 0xff00
> > pflog0: flags=0<> mtu 33208
> > vlan0: flags=8843 mtu 1500
> > inet6 fe80::2e0:4dff:fe30:80e1%vlan0 prefixlen 64 scopeid 0x5
> > inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
> > ether 00:e0:4d:30:80:a0
> > media: Ethernet autoselect (none)
> > status: no carrier
> > vlan: 100 parent interface: rl0
> > vlan1: flags=8843 mtu 1500
> > inet6 fe80::2e0:4dff:fe30:80e1%vlan1 prefixlen 64 scopeid 0x6
> > inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
> > ether 00:e0:4d:30:80:a1
> > media: Ethernet autoselect (none)
> > status: no carrier
> > vlan: 2101 parent interface: rl0
> >
> > In order to configure my vlan i follow this guide:
> > http://people.freebsd.org/~arved/vlan/vlan_en.html
> >
> >> Unless it's absolutly necessicary I don't recommend using dhclient.conf.
> >> I
> >> don't test it.
> >
> > The problem is that i have to get an ip address from my FAI (i'm trying
> to
> > bypass my modem, i have an optical connection with an RJ45 instead of
> RJ11
> > and I need vlan 100 for internet and 2101 for tv)
> >
> >> The current dhclinet scripts don't really support this case. In theory
> if
> >> you
> >> removed support for default routes and resolv.conf setting it should
> >> probably
> >> work, but it's certainly not something I'd expect to work.
> >
> > How do you remove support for default routes and reslov.conf ? I don't
> > understand what do you mean
> >
> >> use vimage :-)
> >
> > If i understand well vimage is used for jail but i need to have those two
> > vlans because my box act like a router and will send data over my switch.
> >
> >
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
