Re: running netmap-ipfw with real NICs
Hi, I tested my scenario. it is true. I could not receive packets in receiver and thought that my scenario is wrong!! My problem in this test solved by using latest version of netmap and netmap-based ipfw. Thanks from Luigi for his great work. -- View this message in context: http://freebsd.1045724.n5.nabble.com/running-netmap-ipfw-with-real-NICs-tp5906992p5911668.html Sent from the freebsd-net mailing list archive at Nabble.com. ___ 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: RX checksum offloading problem
On 12 May 2014, at 03:45, Yonghyeon PYUN wrote: > On Fri, May 09, 2014 at 04:22:36PM +0200, Michael Tuexen wrote: >> >> On 09 May 2014, at 12:46, Michael Tuexen >> wrote: >> >>> On 09 May 2014, at 03:35, Yonghyeon PYUN wrote: >>> On Thu, May 08, 2014 at 08:40:22PM +0200, Michael Tuexen wrote: > On 07 May 2014, at 10:37, Yonghyeon PYUN wrote: > >> On Wed, May 07, 2014 at 10:07:09AM +0200, Michael Tuexen wrote: >>> On 07 May 2014, at 09:56, Yonghyeon PYUN wrote: >>> On Sat, May 03, 2014 at 11:52:47AM +0200, Michael Tuexen wrote: > On 02 May 2014, at 16:02, Bjoern A. Zeeb wrote: > >> >> On 02 May 2014, at 10:22 , Michael Tuexen >> wrote: >> >>> Dear all, >>> >>> during testing I found that FreeBSD head (on a raspberry pi) >>> accepts SCTP packet >>> with bad checksums. After debugging this I figured out that this is >>> a problem with >>> the csum_flags defined in mbuf.h. >>> >>> The SCTP code on its input path checks for CSUM_SCTP_VALID, which >>> is defined in mbuf.h: >>> #define CSUM_SCTP_VALID CSUM_L4_VALID >>> This makes sense: If CSUM_SCTP_VALID is set in csum_flags, the >>> packet is considered >>> to have a correct checksum. >>> >>> For UDP and TCP some drivers calculate the UDP/TCP checksum and set >>> CSUM_DATA_VALID in >>> csum_flags to indicate that the UDP/TCP should consider csum_data >>> to figure out if >>> the packet has a correct checksum. The problem is that >>> CSUM_DATA_VALID is defined as >>> #define CSUM_DATA_VALID CSUM_L4_VALID >>> In this case the semantic is not that the packet has a valid >>> checksum, but the csum_data >>> field contains information. >>> >>> Now the following happens (on the raspberry pi the driver used is >>> dev/usb/net/if_smsc.c >>> >>> 1. A packet is received and if it is not too short, the checksum >>> computed >>> is stored in csum_data and the flag CSUM_DATA_VALID is set. This >>> happens >>> for all IP packets, not only for UDP and TCP packets. >>> 2. In case of SCTP packets, the SCTP interprets CSUM_DATA_VALID as >>> CSUM_SCTP_VALID >>> and accepts the packet. So no SCTP checksum check ever happened. >>> >>> Alternatives to fix this: >>> >>> 1. Change all drivers to set CSUM_DATA_VALID only in case of UDP or >>> TCP packets, since >>> it only makes sense in these cases. >> >> Wait, or for SCTP in cad the crc32 (I think it was) was actually >> checked but not otherwise. This is how it should be imho. It >> seems like a driver bug. > I went through the list of drivers and you are right, it seems to be > a bug > in if_smsc.c. Most of the other drivers check for UDP/TCP, a small > set I can't tell. > I'm not sure how the controller computes TCP/UDP checksum values. It seems the publicly available data sheet was highly sanitized so it was useless to me. The comment in the driver says that the >>> Same for me... controller computes RX checksum after the IPv4 header to the end of ethernet frame. After seeing that comment, three questions popped up: > OK, I did some testing. It looks like the card is just computing the > checksum over the IP payload taking the correct IP header length into > account. 1. Is the controller smart enough to skip IP options header in TCP/UDP checksum offloading? > Yes, I can send fragmented and un-fragmented UDP packets with IP options > and they are handled correctly. Even if the last fragment is too short. I'm assuming you're taking about receiving fragmented UDP packets with RX checksum offloading, right? >>> Correct. 2. How controller handles UDP checksum value 0x(i.e. sender didn't compute UDP checksum)? > This case isn't handled. However, udp_input() looks first for zero > checksums > and only after that in the csum_flags. So it doesn't result in any > problems. > Would you prefer not to set CSUM_DATA_VALID in this case? At least, it correctly updates UDP stats of netstat(1). >>> Let me double check that... >> I double checked it. The statistic counters are incremented. >> Please note that we had a bug in the sending code of head, which >> made it impossible to send UDP packets with 0 checksum. That is >> fixed in >> http://svnweb.freebsd.org/base?view=revision&revision=265776 > > Thanks. > >> >> So any preference whether to report CSUM_DATA_VALID if a UDP packet >> with checksum 0 is
Problem with ipfw table add 0.0.0.0/8
Hi all, Today I discovered a likely problem: # ipfw table 99 add 0.0.0.0/8 # ipfw table 99 list ::/8 0 Is this correct? IPv6? # uname -a FreeBSD mail.xx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #6 r265408: Fri May 9 12:00:40 BRT 2014 r...@mail.xx.com.br:/usr/obj/usr/src/sys/GONDIM amd64 Cheers, Gondim ___ 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: Problem with ipfw table add 0.0.0.0/8
Cute. Same this happen when there are paren around the quad ? -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On May 12, 2014, at 13:43, Marcelo Gondim wrote: > > Hi all, > > Today I discovered a likely problem: > > # ipfw table 99 add 0.0.0.0/8 > > # ipfw table 99 list > ::/8 0 > > Is this correct? IPv6? > > # uname -a > FreeBSD mail.xx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #6 r265408: Fri > May 9 12:00:40 BRT 2014 r...@mail.xx.com.br:/usr/obj/usr/src/sys/GONDIM > amd64 > > Cheers, > Gondim > ___ > 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" smime.p7s Description: S/MIME cryptographic signature
Re: Problem with ipfw table add 0.0.0.0/8
Hi Jason, Same problem. Em 12/05/14 15:02, Jason Hellenthal escreveu: Cute. Same this happen when there are paren around the quad ? -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN On May 12, 2014, at 13:43, Marcelo Gondim wrote: Hi all, Today I discovered a likely problem: # ipfw table 99 add 0.0.0.0/8 # ipfw table 99 list ::/8 0 Is this correct? IPv6? # uname -a FreeBSD mail.xx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #6 r265408: Fri May 9 12:00:40 BRT 2014r...@mail.xx.com.br:/usr/obj/usr/src/sys/GONDIM amd64 Cheers, Gondim ___ 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"
Best practices with network settings for virtualization
I originaly posted this to virtualization@ list week ago. I didn't recieved any answer, so maybe this list is better for questions like the following. I would like to ask some really experienced person - what is the best way to run virtual guests connected to network with public IPs? I think many people run unsecure setup with guests with simple bridged network. I know there are many options with tun, bridge, epair, VDE, Open vSwitch etc., my main concern is the setup of network where each guest can use only predefined MAC and predefined IP(s). If some malicious user or malware in guest OS tried to change MAC od IP, I would like to disallow that or do not allow any offending traffic to reach outside network or any other guest running on the same machine. Guests can be VirtualBox, Bhyve or anything else. I really appreciate any help or ideas. -- Miroslav Lachman ___ 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: 9/STABLE Panic at netisr_dispatch_src w/ em(4) + PF
On Fri, May 2, 2014 at 1:49 PM, Nick Rogers wrote: > Hello, > > I am hoping someone can help me debug a kernel panic I have been experiencing > on one of my production systems. The system is a PF+ALTQ firewall/gateway with > about 1k simultaneous devices behind it at any given time, pushing no more > than 100Mb/s of traffic. I have obtained a crash dump and tried to debug it > with kgdb, but am still at a loss. > > I have completely replaced the hardware to rule out issues with > disk/memory/etc, and it appears to be a kernel issue, likely with e1000 driver > and/or PF. > > The panic seems to happen during times of heavier use, but the frequency is > not very predictable (anywhere from a few times a day to a once a week), so I > feel like its some kind of strange traffic pattern that I am unable to > pinpoint. > > I am using a slightly custom kernel based on GENERIC, mainly to bring in ALTQ > and some other options. > > It may be worth noting that I also have IGB_LEGACY_TX set for the e1000 > driver, although I do not believe that should affect em(4). > > Hoping someone can be of assistance in debugging this problem. I am willing to > test patches and pull in the e1000 driver from HEAD or newer 9/STABLE if that > is advisable. Unfortunately I cannot try 10-STABLE. > > Thanks, > > -Nick Rogers > > > uname -v > FreeBSD 9.2-STABLE #16 r264331M: Thu Apr 10 21:23:18 EDT 2014 > root@fbsd_91_amd64_builder.rgnets.com:/usr/obj/usr/src/sys/RGNETS > > > > Here is the kernel conf... > .. > include GENERIC > > ident RGNETS > > makeoptions MODULES_OVERRIDE="" > > options DEVICE_POLLING > > device crypto > device cryptodev > > options VLAN_ARRAY > > device amdtemp > > # PF > device pf > device pflog > options ALTQ > options ALTQ_CBQ# Class Bases Queuing (CBQ) > options ALTQ_RED# Random Early Detection (RED) > options ALTQ_RIO# RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > options ALTQ_PRIQ # Priority Queuing (PRIQ) > options ALTQ_NOPCC # Required for SMP build > > # PPPoE > options NETGRAPH > options NETGRAPH_ETHER > options NETGRAPH_PPPOE > options NETGRAPH_SOCKET > > # IPsec > device enc > options IPSEC > options IPSEC_FILTERTUNNEL > options IPSEC_NAT_T > .. > > > The crash dump > .. > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 5; apic id = 05 > fault virtual address = 0x10 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x8033d350 > stack pointer= 0x28:0xff83545384b0 > frame pointer= 0x28:0xff83545384c0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq262: em2:rx 0) > trap number = 12 > panic: page fault > cpuid = 5 > KDB: stack backtrace: > #0 0x80956836 at kdb_backtrace+0x66 > #1 0x8091c40e at panic+0x1ce > #2 0x80d31e70 at trap_fatal+0x290 > #3 0x80d321d1 at trap_pfault+0x211 > #4 0x80d327d3 at trap+0x363 > #5 0x80d1b9d3 at calltrap+0x8 > #6 0x8034872d at pf_test_rule+0x17ed > #7 0x8034ba12 at pf_test+0x1032 > #8 0x8035112b at pf_check_in+0x2b > #9 0x809e952e at pfil_run_hooks+0x9e > #10 0x80a5286a at ip_input+0x2ea > #11 0x809e8858 at netisr_dispatch_src+0x218 > #12 0x809df93d at ether_demux+0x14d > #13 0x809dfc1e at ether_nh_input+0x1fe > #14 0x809e8858 at netisr_dispatch_src+0x218 > #15 0x809df85f at ether_demux+0x6f > #16 0x809dfc1e at ether_nh_input+0x1fe > #17 0x809e8858 at netisr_dispatch_src+0x218 > Uptime: 17d7h20m59s > Dumping 2932 out of 12256 MB: (CTRL-C to abort) > ..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > Reading symbols from /boot/kernel/aio.ko...Reading symbols from > /boot/kernel/aio.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/aio.ko > Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from > /boot/kernel/coretemp.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/coretemp.ko > Reading symbols from /boot/kernel/cc_htcp.ko...Reading symbols from > /boot/kernel/cc_htcp.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/cc_htcp.ko > #0 doad
Re: 9/STABLE Panic at netisr_dispatch_src w/ em(4) + PF
Nick, I'm very busy with some critical internal deadlines, I will look at this when I can come up for air, but please be patient. Jack On Mon, May 12, 2014 at 4:56 PM, Nick Rogers wrote: > On Fri, May 2, 2014 at 1:49 PM, Nick Rogers wrote: > > Hello, > > > > I am hoping someone can help me debug a kernel panic I have been > experiencing > > on one of my production systems. The system is a PF+ALTQ > firewall/gateway with > > about 1k simultaneous devices behind it at any given time, pushing no > more > > than 100Mb/s of traffic. I have obtained a crash dump and tried to debug > it > > with kgdb, but am still at a loss. > > > > I have completely replaced the hardware to rule out issues with > > disk/memory/etc, and it appears to be a kernel issue, likely with e1000 > driver > > and/or PF. > > > > The panic seems to happen during times of heavier use, but the frequency > is > > not very predictable (anywhere from a few times a day to a once a week), > so I > > feel like its some kind of strange traffic pattern that I am unable to > > pinpoint. > > > > I am using a slightly custom kernel based on GENERIC, mainly to bring in > ALTQ > > and some other options. > > > > It may be worth noting that I also have IGB_LEGACY_TX set for the e1000 > > driver, although I do not believe that should affect em(4). > > > > Hoping someone can be of assistance in debugging this problem. I am > willing to > > test patches and pull in the e1000 driver from HEAD or newer 9/STABLE if > that > > is advisable. Unfortunately I cannot try 10-STABLE. > > > > Thanks, > > > > -Nick Rogers > > > > > > uname -v > > FreeBSD 9.2-STABLE #16 r264331M: Thu Apr 10 21:23:18 EDT 2014 > > root@fbsd_91_amd64_builder.rgnets.com:/usr/obj/usr/src/sys/RGNETS > > > > > > > > Here is the kernel conf... > > > .. > > include GENERIC > > > > ident RGNETS > > > > makeoptions MODULES_OVERRIDE="" > > > > options DEVICE_POLLING > > > > device crypto > > device cryptodev > > > > options VLAN_ARRAY > > > > device amdtemp > > > > # PF > > device pf > > device pflog > > options ALTQ > > options ALTQ_CBQ# Class Bases Queuing (CBQ) > > options ALTQ_RED# Random Early Detection (RED) > > options ALTQ_RIO# RED In/Out > > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > > options ALTQ_PRIQ # Priority Queuing (PRIQ) > > options ALTQ_NOPCC # Required for SMP build > > > > # PPPoE > > options NETGRAPH > > options NETGRAPH_ETHER > > options NETGRAPH_PPPOE > > options NETGRAPH_SOCKET > > > > # IPsec > > device enc > > options IPSEC > > options IPSEC_FILTERTUNNEL > > options IPSEC_NAT_T > > > .. > > > > > > The crash dump > > > .. > > > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > are > > welcome to change it and/or distribute copies of it under certain > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > details. > > This GDB was configured as "amd64-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 5; apic id = 05 > > fault virtual address = 0x10 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x8033d350 > > stack pointer= 0x28:0xff83545384b0 > > frame pointer= 0x28:0xff83545384c0 > > code segment = base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 12 (irq262: em2:rx 0) > > trap number = 12 > > panic: page fault > > cpuid = 5 > > KDB: stack backtrace: > > #0 0x80956836 at kdb_backtrace+0x66 > > #1 0x8091c40e at panic+0x1ce > > #2 0x80d31e70 at trap_fatal+0x290 > > #3 0x80d321d1 at trap_pfault+0x211 > > #4 0x80d327d3 at trap+0x363 > > #5 0x80d1b9d3 at calltrap+0x8 > > #6 0x8034872d at pf_test_rule+0x17ed > > #7 0x8034ba12 at pf_test+0x1032 > > #8 0x8035112b at pf_check_in+0x2b > > #9 0x809e952e at pfil_run_hooks+0x9e > > #10 0x80a5286a at ip_input+0x2ea > > #11 0x809e8858 at netisr_dispatch_src+0x218 > > #12 0x809df93d at ether_demux+0x14d > > #13 0x809dfc1e at ether_nh_input+0x1fe > > #14 0x809e8858 at netisr_dispatch_src+0x218 > > #15 0x809df85f at ether_demux+0x6f > > #16 0x809dfc1e at ether_nh_input+0x1fe > > #17 0x809e8858 at netisr_dispatch_src+0x218 > > Uptime: 17d7h20m59s > > Dumping 2932 out of 12256 MB: (CTRL-C to abort) > > ..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > > > Re
Re: 9/STABLE Panic at netisr_dispatch_src w/ em(4) + PF
On Mon, May 12, 2014 at 5:16 PM, Jack Vogel wrote: > Nick, > > I'm very busy with some critical internal deadlines, I will look at this > when I can > come up for air, but please be patient. Thank you. > > Jack > > > > On Mon, May 12, 2014 at 4:56 PM, Nick Rogers wrote: >> >> On Fri, May 2, 2014 at 1:49 PM, Nick Rogers wrote: >> > Hello, >> > >> > I am hoping someone can help me debug a kernel panic I have been >> > experiencing >> > on one of my production systems. The system is a PF+ALTQ >> > firewall/gateway with >> > about 1k simultaneous devices behind it at any given time, pushing no >> > more >> > than 100Mb/s of traffic. I have obtained a crash dump and tried to debug >> > it >> > with kgdb, but am still at a loss. >> > >> > I have completely replaced the hardware to rule out issues with >> > disk/memory/etc, and it appears to be a kernel issue, likely with e1000 >> > driver >> > and/or PF. >> > >> > The panic seems to happen during times of heavier use, but the frequency >> > is >> > not very predictable (anywhere from a few times a day to a once a week), >> > so I >> > feel like its some kind of strange traffic pattern that I am unable to >> > pinpoint. >> > >> > I am using a slightly custom kernel based on GENERIC, mainly to bring in >> > ALTQ >> > and some other options. >> > >> > It may be worth noting that I also have IGB_LEGACY_TX set for the e1000 >> > driver, although I do not believe that should affect em(4). >> > >> > Hoping someone can be of assistance in debugging this problem. I am >> > willing to >> > test patches and pull in the e1000 driver from HEAD or newer 9/STABLE if >> > that >> > is advisable. Unfortunately I cannot try 10-STABLE. >> > >> > Thanks, >> > >> > -Nick Rogers >> > >> > >> > uname -v >> > FreeBSD 9.2-STABLE #16 r264331M: Thu Apr 10 21:23:18 EDT 2014 >> > root@fbsd_91_amd64_builder.rgnets.com:/usr/obj/usr/src/sys/RGNETS >> > >> > >> > >> > Here is the kernel conf... >> > >> > .. >> > include GENERIC >> > >> > ident RGNETS >> > >> > makeoptions MODULES_OVERRIDE="" >> > >> > options DEVICE_POLLING >> > >> > device crypto >> > device cryptodev >> > >> > options VLAN_ARRAY >> > >> > device amdtemp >> > >> > # PF >> > device pf >> > device pflog >> > options ALTQ >> > options ALTQ_CBQ# Class Bases Queuing (CBQ) >> > options ALTQ_RED# Random Early Detection (RED) >> > options ALTQ_RIO# RED In/Out >> > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) >> > options ALTQ_PRIQ # Priority Queuing (PRIQ) >> > options ALTQ_NOPCC # Required for SMP build >> > >> > # PPPoE >> > options NETGRAPH >> > options NETGRAPH_ETHER >> > options NETGRAPH_PPPOE >> > options NETGRAPH_SOCKET >> > >> > # IPsec >> > device enc >> > options IPSEC >> > options IPSEC_FILTERTUNNEL >> > options IPSEC_NAT_T >> > >> > .. >> > >> > >> > The crash dump >> > >> > .. >> > >> > GNU gdb 6.1.1 [FreeBSD] >> > Copyright 2004 Free Software Foundation, Inc. >> > GDB is free software, covered by the GNU General Public License, and you >> > are >> > welcome to change it and/or distribute copies of it under certain >> > conditions. >> > Type "show copying" to see the conditions. >> > There is absolutely no warranty for GDB. Type "show warranty" for >> > details. >> > This GDB was configured as "amd64-marcel-freebsd"... >> > >> > Unread portion of the kernel message buffer: >> > >> > >> > Fatal trap 12: page fault while in kernel mode >> > cpuid = 5; apic id = 05 >> > fault virtual address = 0x10 >> > fault code = supervisor read data, page not present >> > instruction pointer = 0x20:0x8033d350 >> > stack pointer= 0x28:0xff83545384b0 >> > frame pointer= 0x28:0xff83545384c0 >> > code segment = base 0x0, limit 0xf, type 0x1b >> > = DPL 0, pres 1, long 1, def32 0, gran 1 >> > processor eflags = interrupt enabled, resume, IOPL = 0 >> > current process = 12 (irq262: em2:rx 0) >> > trap number = 12 >> > panic: page fault >> > cpuid = 5 >> > KDB: stack backtrace: >> > #0 0x80956836 at kdb_backtrace+0x66 >> > #1 0x8091c40e at panic+0x1ce >> > #2 0x80d31e70 at trap_fatal+0x290 >> > #3 0x80d321d1 at trap_pfault+0x211 >> > #4 0x80d327d3 at trap+0x363 >> > #5 0x80d1b9d3 at calltrap+0x8 >> > #6 0x8034872d at pf_test_rule+0x17ed >> > #7 0x8034ba12 at pf_test+0x1032 >> > #8 0x8035112b at pf_check_in+0x2b >> > #9 0x809e952e at pfil_run_hooks+0x9e >> > #10 0x80a5286a at ip_input+0x2ea >> > #11 0x809e8858 at netisr_dispatch_src+0x218 >> > #12 0x809df93d at ether_demux+0x14d >> > #13 0x809dfc1e at ether_nh_input+0x1fe >> > #14 0x809e8858 at netisr_dispatch_src+0x218 >> > #15 0x809df85f at ether_
Re: kern/189531: [fxp] Wake on Lan (WOL) enabled for Intel 82562EZ ethernet adapter, but WOL does not work
Old Synopsis: Wake on Lan (WOL) enabled for Intel 82562EZ ethernet adapter, but WOL does not work New Synopsis: [fxp] Wake on Lan (WOL) enabled for Intel 82562EZ ethernet adapter, but WOL does not work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 13 04:47:02 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=189531 ___ 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: RX checksum offloading problem
On Mon, May 12, 2014 at 01:22:03PM +0200, Michael Tuexen wrote:
> On 12 May 2014, at 03:36, Yonghyeon PYUN wrote:
>
> > On Fri, May 09, 2014 at 12:46:48PM +0200, Michael Tuexen wrote:
> >> On 09 May 2014, at 03:35, Yonghyeon PYUN wrote:
> >>
[...]
> > Oops, sorry. You're right. Probably I was confused with old memory
> > when I worked on that area. I've quickly read IP reassembly code
> > again and as you said, it should work. However it seems there is a
> > checksumming bug here.
> >
> > /*
> > * In order to do checksumming faster we do 'end-around carry' here
> > * (and not in for{} loop), though it implies we are not going to
> > * reassemble more than 64k fragments.
> > */
> > m->m_pkthdr.csum_data =
> > (m->m_pkthdr.csum_data & 0x) + (m->m_pkthdr.csum_data >> 16);
> >
> > I guess the line above didn't account possible carry happened after
> > the computation. Probably it could be rewritten as the following.
> >
> > while (m->m_pkthdr.csum_data & 0x)
> > m->m_pkthdr.csum_data = (m->m_pkthdr.csum_data & 0x) +
> > (m->m_pkthdr.csum_data >> 16);
> I think you are right here. Good catch. Will you fix it?
>
Done in r265942.
___
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: TX Checksum offloading issue with re interfaces
On Mon, May 12, 2014 at 01:09:18PM +0200, Michael Tuexen wrote: > On 12 May 2014, at 06:38, Yonghyeon PYUN wrote: > > > On Fri, May 09, 2014 at 12:33:24PM +0200, Michael Tuexen wrote: > >> On 09 May 2014, at 03:47, Yonghyeon PYUN wrote: > >> > >>> On Thu, May 08, 2014 at 08:50:48PM +0200, Michael Tuexen wrote: > Dear all, > > while testing checksum offloading of UDP packets over IP with IP > options, I figured > out that my card > > dev.re.1.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet > dev.re.1.%driver: re > dev.re.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PE1F.LAN2 > dev.re.1.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x1734 > subdevice=0x1159 class=0x02 > dev.re.1.%parent: pci13 > dev.re.1.stats: -1 > dev.re.1.int_rx_mod: 65 > > computes the UDP checksum, but stores it in the packet at the place, > where it would be, > if there are no IP options. So it corrupts the options in the packet... > > I looked at sys/dev/re/if_re.c, but couldn't figure out how to fix it. > Any idea? > > >>> > >>> re(4) has a very long history on its broken TX checksum offloading. > >>> So re(4) has many workarounds for known issues on several variants. > >>> re(4) controllers support TX IPv4/TCP/UDP checksum offloading. For > >>> 8168C/8168CP, TX IPv4 checksum offloading was disabled due to > >>> generation of corrupted frames. > >>> Could you show me the dmesg output(only re(4)/rgephy(4))? > >> > >>> The vendor uses the same PCI id for its RTL8168/8111 family chips > >>> so dmesg output is necessary to know exact controller revision. > >> Sure (re1 was used during the test): > >> re0: port > >> 0x8000-0x80ff mem 0xf6104000-0xf6104fff,0xf610-0xf6103fff irq 16 at > >> device 0.0 on pci12 > >> re0: Using 1 MSI-X message > >> re0: Chip rev. 0x2880 > >> re0: MAC rev. 0x0020 > >> miibus0: on re0 > >> rgephy0: PHY 1 on miibus0 > >> rgephy0: none, 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: 00:19:99:85:31:d9 > >> re1: port > >> 0x9000-0x90ff mem 0xf5c2-0xf5c20fff,0xf620-0xf620 irq 17 at > >> device 0.0 on pci13 > >> re1: Using 1 MSI-X message > >> re1: Chip rev. 0x3c80 > >> re1: MAC rev. 0x0030 > >> miibus1: on re1 > >> rgephy1: PHY 1 on miibus1 > >> rgephy1: none, 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 > >> re1: Ethernet address: 00:19:99:7e:c7:46 > >> > > It seems you have two variants. > You are right, I didn't know. Both are on-board interfaces... > > re0 is RTL8168DP and re1 is RTL8168CP. Do you see the issue on > > both controllers? I guess you may see the issue on re1 only since > > you've posted dev.re.1 output. I've attached a diff which may > It wasn't intentionally, but by accident, based on the addresses > I was using. However, I now tested both interfaces and re0 works > without any patch, but re1 needs your patch. > > address the issue on re1 interface. If you see the issue on re0, > > I have to change the diff to include RTL8168D. > Your patch looks good. Please go ahead and commit it. > Thanks for your help! Fixed in r265943. Thanks for testing! ___ 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"
