Hello, about whether netmap under e1000e cannot receive the package problem help look? Thank you
Luigi Rizzo Hello, thank you for your selfless contributions netmap the fast packet I/O framework, I have a little problem now, the thing is such, do not know if you can help me to have a look? Thank you I do the test in the Linux kernel version 3.0.80 below, I discovered that netmap cannot receive packets, machine I is the following I use the lsmod command output, that I should have been loaded with netmap_lin.ko and e1000e.ko [root@localhost ~]# lsmod Module Size Used by e1000e 20996 0 netmap_lin253984 1 e1000e Then I use tcpdump -i eth1 to capture can normally receive all packets But I tcpdump -i netmap:eth1 [root@centos examples]# tcpdump -i netmap:eth1 Pcap_netmap_activate device netmap:eth1 priv 0x1bac600 FD 3 ports 0..0 Pcap_netmap_ioctl eth1 IOCTL 0x8913 returns 0 Pcap_netmap_ioctl eth1 IOCTL 0x8914 returns 0 Tcpdump: verbose output suppressed, use -v or -vv for full protocol decode Listening on netmap:eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 08:25:26.122361 IP 192.168.188.2.netbios-ns > 192.168.188.255.netbios-ns: NBT UDP PACKET (137): QUERY; REQUEST; BROADCAST 08:25:26.871923 IP 192.168.188.2.netbios-ns > 192.168.188.255.netbios-ns: NBT UDP PACKET (137): QUERY; REQUEST; BROADCAST 08:25:27.622484 IP 192.168.188.2.netbios-ns > 192.168.188.255.netbios-ns: NBT UDP PACKET (137): QUERY; REQUEST; BROADCAST Not receiving any useful package, I am very confused do not know is what reason // I use the following netmap/example tools pkt-gen test does not receive all the packages below is my operation results [root@centos examples]#./pkt-gen -i eth1 -f R 30.524029 main [1624] interface is eth1 30.524527 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 30.524550 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 30.676782 main [1807] mapped 334980KB at 0x7fede9c9b000 Receiving from netmap:eth1: 1 queues, 1 threads and 1 cpus. 30.676899 main [1887] Wait 2 secs for PHY reset 32.676992 main [1889] Ready... 32.677044 nm_open [457] overriding ifname eth1 ringid 0x0 flags 0x1 33.678190 receiver_body [1170] waiting for initial packets, poll returns 00 33.678265 main_thread [1421] 0 PPS (0 PKTS in 1001121 USEC) 34.679292 receiver_body [1170] waiting for initial packets, poll returns 00 34.679437 main_thread [1421] 0 PPS (0 PKTS in 1001173 USEC) 35.680347 receiver_body [1170] waiting for initial packets, poll returns 00 35.680595 main_thread [1421] 0 PPS (0 PKTS in 1001158 USEC) 36.681386 receiver_body [1170] waiting for initial packets, poll returns 00 36.681634 main_thread [1421] 0 PPS (0 PKTS in 1001038 USEC) 37.682467 receiver_body [1170] waiting for initial packets, poll returns 00 37.682707 main_thread [1421] 0 PPS (0 PKTS in 1001074 USEC) 38.683502 receiver_body [1170] waiting for initial packets, poll returns 00 38.683870 main_thread [1421] 0 PPS (0 PKTS in 1001163 USEC) 39.684556 receiver_body [1170] waiting for initial packets, poll returns 00 39.685022 main_thread [1421] 0 PPS (0 PKTS in 1001152 USEC) 40.685591 receiver_body [1170] waiting for initial packets, poll returns 00 40.686056 main_thread [1421] 0 PPS (0 PKTS in 1001034 USEC) 41.686632 receiver_body [1170] waiting for initial packets, poll returns 00 41.687193 main_thread [1421] 0 PPS (0 PKTS in 1001137 USEC) 42.687664 receiver_body [1170] waiting for initial packets, poll returns 00 42.688353 main_thread [1421] 0 PPS (0 PKTS in 1001160 USEC) 43.688707 receiver_body [1170] waiting for initial packets, poll returns 00 43.689502 main_thread [1421] 0 PPS (0 PKTS in 1001149 USEC) 44.689751 receiver_body [1170] waiting for initial packets, poll returns 00 44.690549 main_thread [1421] 0 PPS (0 PKTS in 1001047 USEC) 45.690784 receiver_body [1170] waiting for initial packets, poll returns 00 45.691641 main_thread [1421] 0 PPS (0 PKTS in 1001092 USEC) 46.691825 receiver_body [1170] waiting for initial packets, poll returns 00 46.692807 main_thread [1421] 0 PPS (0 PKTS in 1001166 USEC) 47.692857 receiver_body [1170] waiting for initial packets, poll returns 00 47.693962 main_thread [1421] 0 PPS (0 PKTS in 1001154 USEC) 48.693892 receiver_body [1170] waiting for initial packets, poll returns 00 48.694996 main_thread [1421] 0 PPS (0 PKTS in 1001035 USEC) 49.694926 receiver_body [1170] waiting for initial packets, poll returns 00 49.696132 main_thread [1421] 0 PPS (0 PKTS in 1001135 USEC) 50.695958 receiver_body [1170] waiting for initial packets, poll returns 00 50.697295 main_thread [1421] 0 PPS (0 PKTS in 1001164 USEC) 51.696997 receiver_body [1170] waiting for initial packets, poll returns 00 51.698451
Re: pf and ipv6 pmtu discovery not working
Hi! On Thu, May 01, 2014 at 02:52:47PM +0200, Hellmuth Michaelis wrote: > for some time now i'm trying to nail down a phenomenon of hanging ipv6 > transfers, it looks to me like there is a problem of getting ipv6 path > mtu discovery right when using FreeBSD and pf. > > When the "set skip on fxp0" line in pf.conf is removed, the above > described pmtu scenario does not work anymore: I'm suffering from the same (probably) problem. Has there been any progress towards fixing this? Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer signature.asc Description: Digital signature
Re: Can you create a FreeBSD gateway, with private IPs, without NAT/divert ?
On Sun, Jun 8, 2014 at 3:12 AM, Erich Dollansky wrote: > Hi, > > On Sat, 7 Jun 2014 09:48:39 -0700 (PDT) > None Secure via freebsd-net wrote: > > > Yes, but in this case BOTH IPs of the gateway - both the external and > > the internal interfaces - are non-routable IPs, and so is my ISP > > cable modem. > > > > 192.168.1.1 is the cable modem > > 192.168.1.2 is external interface of my FreeBSD > > 10.10.10.1 is internal interface of my FreeBSD > > > I have had before the reverse situation. 10.x.x.x was the external > address and 192.168.x.x the internal. There have been two interfaces in > the machine. I cannot remember that I have had any problems with this. > I have now an external router so I do not need to use FreeBSD for this. > > Erich > It's sad that they choose CGN in the first place :( But now that they have, couldn't you ask them to give you a /24 subnet of that rfc1918 block? Then you wouldn't really need a gateway at all, just a firewall (which should block arp and so on. And as stated by others: routing/forwarding table really has no notion about human "constraints" on IP addresses, kernel will happily forward traffic from one rfc1918 block to another. That being said, your ISP is running nat, from 192.168.1.1 to some public ip. If the ISP sees traffic from 10.10.10.0/24 ( just guessing about the /24), they will be confused, which is why you need to run nat to translate those internal addresses to your external IP. As for ipfw, could you show us the rules that get added? If it uses divert you definitely should be able to send to different natd processes, as divert sends the traffic to a specified port. If you want to use in-kernel nat it might be a bit trickier, but what if you the process in question in a jail? Then you could easily distinguish it in ipfw. Best regards Andreas ___ 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:Hello, about whether netmap under e1000e cannot receive the package problem help look? Thank you
Hello, I solved, the original netmap can not take the initiative to set the promiscuous, thank you I found a problem that I used Libpcap capture, like CPU load is not high, But I use netmap+libpcap CPU load is very high, is this normal? Thank you -- Original -- From: "lyerwtyr";; Date: Sun, Jun 8, 2014 06:38 PM To: "net"; Subject: Hello, about whether netmap under e1000e cannot receive the package problem help look? Thank you Luigi Rizzo Hello, thank you for your selfless contributions netmap the fast packet I/O framework, I have a little problem now, the thing is such, do not know if you can help me to have a look? Thank you I do the test in the Linux kernel version 3.0.80 below, I discovered that netmap cannot receive packets, machine I is the following I use the lsmod command output, that I should have been loaded with netmap_lin.ko and e1000e.ko [root@localhost ~]# lsmod Module Size Used by e1000e 20996 0 netmap_lin253984 1 e1000e Then I use tcpdump -i eth1 to capture can normally receive all packets But I tcpdump -i netmap:eth1 [root@centos examples]# tcpdump -i netmap:eth1 Pcap_netmap_activate device netmap:eth1 priv 0x1bac600 FD 3 ports 0..0 Pcap_netmap_ioctl eth1 IOCTL 0x8913 returns 0 Pcap_netmap_ioctl eth1 IOCTL 0x8914 returns 0 Tcpdump: verbose output suppressed, use -v or -vv for full protocol decode Listening on netmap:eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 08:25:26.122361 IP 192.168.188.2.netbios-ns > 192.168.188.255.netbios-ns: NBT UDP PACKET (137): QUERY; REQUEST; BROADCAST 08:25:26.871923 IP 192.168.188.2.netbios-ns > 192.168.188.255.netbios-ns: NBT UDP PACKET (137): QUERY; REQUEST; BROADCAST 08:25:27.622484 IP 192.168.188.2.netbios-ns > 192.168.188.255.netbios-ns: NBT UDP PACKET (137): QUERY; REQUEST; BROADCAST Not receiving any useful package, I am very confused do not know is what reason // I use the following netmap/example tools pkt-gen test does not receive all the packages below is my operation results [root@centos examples]#./pkt-gen -i eth1 -f R 30.524029 main [1624] interface is eth1 30.524527 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 30.524550 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 30.676782 main [1807] mapped 334980KB at 0x7fede9c9b000 Receiving from netmap:eth1: 1 queues, 1 threads and 1 cpus. 30.676899 main [1887] Wait 2 secs for PHY reset 32.676992 main [1889] Ready... 32.677044 nm_open [457] overriding ifname eth1 ringid 0x0 flags 0x1 33.678190 receiver_body [1170] waiting for initial packets, poll returns 00 33.678265 main_thread [1421] 0 PPS (0 PKTS in 1001121 USEC) 34.679292 receiver_body [1170] waiting for initial packets, poll returns 00 34.679437 main_thread [1421] 0 PPS (0 PKTS in 1001173 USEC) 35.680347 receiver_body [1170] waiting for initial packets, poll returns 00 35.680595 main_thread [1421] 0 PPS (0 PKTS in 1001158 USEC) 36.681386 receiver_body [1170] waiting for initial packets, poll returns 00 36.681634 main_thread [1421] 0 PPS (0 PKTS in 1001038 USEC) 37.682467 receiver_body [1170] waiting for initial packets, poll returns 00 37.682707 main_thread [1421] 0 PPS (0 PKTS in 1001074 USEC) 38.683502 receiver_body [1170] waiting for initial packets, poll returns 00 38.683870 main_thread [1421] 0 PPS (0 PKTS in 1001163 USEC) 39.684556 receiver_body [1170] waiting for initial packets, poll returns 00 39.685022 main_thread [1421] 0 PPS (0 PKTS in 1001152 USEC) 40.685591 receiver_body [1170] waiting for initial packets, poll returns 00 40.686056 main_thread [1421] 0 PPS (0 PKTS in 1001034 USEC) 41.686632 receiver_body [1170] waiting for initial packets, poll returns 00 41.687193 main_thread [1421] 0 PPS (0 PKTS in 1001137 USEC) 42.687664 receiver_body [1170] waiting for initial packets, poll returns 00 42.688353 main_thread [1421] 0 PPS (0 PKTS in 1001160 USEC) 43.688707 receiver_body [1170] waiting for initial packets, poll returns 00 43.689502 main_thread [1421] 0 PPS (0 PKTS in 1001149 USEC) 44.689751 receiver_body [1170] waiting for initial packets, poll returns 00 44.690549 main_thread [1421] 0 PPS (0 PKTS in 1001047 USEC) 45.690784 receiver_body [1170] waiting for initial packets, poll returns 00 45.691641 main_thread [1421] 0 PPS (0 PKTS in 1001092 USEC) 46.691825 receiver_body [1170] waiting for initial packets, poll returns 00 46.692807 main_thread [1421] 0 PPS (0 PKTS in 1001166 USEC) 47.692857 receiver_body [1170] waiting for initial packets, poll returns 00 47.693962 main_thread [1421] 0 PPS (0 PKTS in 1001154 USEC) 48.693892 receiver_bod
Re: ECN marking implenetation for dummynet
On Sun, Jun 1, 2014 at 12:31 AM, hiren panchasara wrote: > On Tue, Apr 8, 2014 at 9:14 PM, hiren panchasara > wrote: >> On Tue, Apr 8, 2014 at 8:46 PM, Adrian Chadd wrote: >>> Hi! Cool! can you file a FreeBSD PR with this? >> >> I'm testing this patch right now. >> >> I will make sure it doesn't get lost. :-) > > Committed as r266941. I wish to MFC this change and following actual dctcp changes (which I'll commit to -head in coming weeks) to 10. Let me know if there is any objection to it. cheers, Hiren ___ 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"
