Label & Package 2015
Hello , Would you be interested in acquiring contacts from Label & Package Printing Industry Lists 2015? Which includes complete verified email addresses of - All Key Decision makers List, All C-level executives List of - Manufacturers, Packaging Professionals, Food & Beverages Manufacturers, Web printing Companies, Overprinting & Inspection Professionals, Pre-press, Radio frequency Professionals, Security Managers, Industrial Production Managers, Food Batch makers, Book/Magazines Publishers, Equipment Manufacturers, Foil Manufacturers, Rubber & Plastic Manufacturers, Graphic Designers, Supply & logistics Managers, Product development managers, Buyers, Suppliers, Importers/Exporters and many more! across US/UK/Global. Our List Includes : Label printers/converters Flexible packaging printers/converters Folding carton printers/converters Packaging printers/converters General printers/converters Brand owners Label designers Industry suppliers and many more.. If your target audience is not mentioned above, kindly let me know. Kindly, confirm your exact target audience (Target Industry/Geography/ Job Titles) so that we can send you few sample records for your internal review. Looking forward to connect with you! Thanks, Adriana Parker | Inside Sales Global E-mail lists We are expertise in:- B2B and B2C Email List, Email Appending, Reverse Appending, Email Campaign, Data Appending, Fax Appending, Phone Appending Services. ___ 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"
ifconfig greX create disables IPv6 forwarding
For some reason, every time I create a GRE interface on a FreeBSD IPv6 gateway, net.inet6.ip6.forwarding is disabled. As long as I manually re-enable it with sysctl, both the GRE tunnel and the IPv6 network behind this machine will continue to work; however, it's certainly far from ideal. There's nothing in the log to indicate exactly what's going on here: Feb 9 11:23:08 router rtadvd[27251]: interface added (idx=8) Feb 9 11:23:08 router devd: Executing '/etc/pccard_ether gre0 start' Feb 9 11:23:21 router rtadvd[27251]: non-zero lifetime RA but net.inet6.ip6.forwarding=0. Ignored. Feb 9 11:23:53 router last message repeated 2 times Nor is there anything about it in dmesg. # uname -a FreeBSD router.corbe.net 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 -DAniel ___ 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: ifconfig greX create disables IPv6 forwarding
On 09/02/2015 16:34, Daniel Corbe wrote: For some reason, every time I create a GRE interface on a FreeBSD IPv6 gateway, net.inet6.ip6.forwarding is disabled. As long as I manually re-enable it with sysctl, both the GRE tunnel and the IPv6 network behind this machine will continue to work; however, it's certainly far from ideal. I stumbled acro I discovered this in January. See this thread: http://lists.freebsd.org/pipermail/freebsd-net/2015-January/040797.html Are you enabling forwarding using ipv6_gateway_enable in rc.conf, or are you just setting net.inet6.ip6.forwarding to 1 in sysctl.conf? devd gets involved running /etc/rc.d/netif start and that seems to check (and set) the forwarding sysctls based on the rc.conf entries - so if you've set them "manually" they get reset when a new interface is brought up. Adding ipv6_gateway_enable="YES" in /etc/rc.conf should fix this. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ifconfig greX create disables IPv6 forwarding
Paul Thornton writes: > On 09/02/2015 16:34, Daniel Corbe wrote: >> >> For some reason, every time I create a GRE interface on a FreeBSD IPv6 >> gateway, net.inet6.ip6.forwarding is disabled. As long as I manually >> re-enable it with sysctl, both the GRE tunnel and the IPv6 network >> behind this machine will continue to work; however, it's certainly far >> from ideal. > I stumbled acro > > I discovered this in January. See this thread: > > http://lists.freebsd.org/pipermail/freebsd-net/2015-January/040797.html > > Are you enabling forwarding using ipv6_gateway_enable in rc.conf, or > are you just setting net.inet6.ip6.forwarding to 1 in sysctl.conf? > > devd gets involved running /etc/rc.d/netif start and that seems to > check (and set) the forwarding sysctls based on the rc.conf entries - > so if you've set them "manually" they get reset when a new interface > is brought up. > > Adding ipv6_gateway_enable="YES" in /etc/rc.conf should fix this. > Embarrassingly enough, the problem wound up being I had ipv6_enable_gateway instead of ipv6_gateway_enable. I'm also setting net.inet6.ip6.forwarding=1 manually in sysctl.conf so that's sort of why it ever worked to begin with. Thanks though. Some times all you need is a second set of eyes on a problem. -Daniel ___ 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: IEE1588/PTP support for NIC drivers ?
On 5 Feb 2015, at 20:50, Olivier Cochard-Labbé wrote: Hi, Some network cards support IEE1588 hardware timestamp (like some Intel card), but their drivers didn't support this feature. I beleive there is a kernel feature missing for this suppport. Searching on the archive's mailing-list, I've found this post about some legal issue: https://lists.freebsd.org/pipermail/freebsd-net/2007-October/015512.html Is still a legal problem or just a missing feature ? Missing feature. We need an API and the like to get this going. I've taken various stabs at it in the past and will likely do so again but if anyone has working code I'd be more than happy to review. Best, George ___ 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: Adding new media types to if_media.h
On 8 Feb 2015, at 22:41, Mike Karels wrote: Sorry to reply to a thread after such a long delay, but I think it is unresolved, and needs more discussion. I'd like to elaborate a bit on my goals and proposal. I believe Adrian has newer thoughts than have been circulated here as well. The last message(s) have gone to freebsd-arch and freebsd-net. If someone wants to pick one, we could consolidate, but this seems relevant to both. I'm going to top-post to try to summarize and extend the discussion, but the preceding emails follow for reference. To recap: the existing if_media interface is running out of steam, at least in that the "Media variant" field, with 5 bits, is going to be insufficient to express existing 40 Gb/s variants. The if_media media type is a 32-bit int with a bunch of sub-fields for type (e.g. Ethernet), subtype/variant (e.g. 10baseT, 10base5, 1000baseT, etc), flags, and some MII-related fields. I made a proposal to extend the interface in a small way, specifically to replace the "media word" with a 64-bit int that is mostly the same, but has a new, larger variant/subtype field. The main reason for this proposal is to maintain the driver KPI (glimpse showed me 240 inclusions of if_media.h in the kernel in 8.2). That interface includes an initialization using a scalar value of fields ORed with each other. It would also be easy to preserve a 32-bit user-level API/ABI that can express most of the current state, with a subtype/variant field value reserved for "other" (there is already one for "unknown", but that is not quite the same). fwiw, I found 45 references to this user-level API in our tree, including both base and "ports"-type software, which includes libpcap, snmpd, dhclient, quagga, xorp, atm, devd, and rtsold, which argues for a backward-compatible API/ABI as well as a more-complete current interface for ifconfig at least. More generally, I see two problems with the existing if_media interface: 1. It doesn't have enough bits for all the fields, in particular, variant/ subtype for Ethernet. That is the immediate issue. 2. The interface is not sufficiently generic; it was designed around Ethernet including MII, token ring, FDDI, and a few other interface types. Some of the fields like "instance" are primarily for MII as far as I know, and are basically unused. It is definitely not sufficient for 802.11, which has rolled its own interfaces. To solve the second problem, I think the right approach would be to reduce this interface to a truly generic one, such as media type (e.g. Ethernet), generic flags, and perhaps generic status. Then there should be a separate media-specific interface for each type, such as Ethernet and 802.11. To a small extent, we already have that. Solving the second, more general problem, requires a whole new driver KPI that will require surgery to every driver, which is not an exercise that I would consider. Using a separate int for each existing field, as proposed, would break the driver KPI, but would not really make the interface generic. Trying to make a single interface with the union of all network interface requirements seems like a bad idea to me (we failed last time; the "we" is BSDi, where I was the architect when this interface was first designed). (No, I didn't design this interface.) Solving the first problem only, I think it is preferable to preserve a compatible driver KPI, which means using a scalar value encoding what is necessary. Although that interface is rather Ethernet-centric, that is really what it is used for. An additional, selfish goal is to make it easy to back-port drivers using the new interface to older versions (which I am quite likely to do). Preserving the KPI and general user API will be highly useful there. I'd be likely to do a 11-style version of ifconfig personally, but it might not be difficult to do in a more general way. I am willing to do a prototype for -current for evaluation. Comments, alternatives, ? I agree with your statements above and I'd like to see the prototype. Best, George Mike From: Eric Joyner Date: January 6, 2015 4:50:28 PM CST To: m...@karels.net Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , John Baldwin , Jack Vogel , "freebsd-a...@freebsd.org" Subject: Re: Adding new media types to if_media.h Then going with what Mike says about leaving backwards compatibility, I suppose we should do something like what Adrian suggested, and add a separate struct. We can indicate that the separate struct exists by setting the media type value in the if_media word to 0xc0, since that's the last unused value. Then existing programs won't have to support any new features if they don't want to. Adrian -- where can I look for more information on what net80211 does for media types? Do you mean what it does with MCS values, or something more; I've looked at it a bit, but I do
Re: Problems with IP fragments (was: Problems with DNSSEC -- answer in fragmented UDP doesn't work)
On Wed, 28-Jan-2015 at 10:04:57 -0800, Freddie Cash wrote: > On Wed, Jan 28, 2015 at 9:53 AM, Lev Serebryakov wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On 28.01.2015 20:38, Matthew Seaman wrote: > > > > > What do you get if you run the reply size test at DNS-OARC ? > > > > > > https://www.dns-oarc.net/oarc/services/replysizetest > > 0 lines (empty answer) at CURRENT, only "rst.x1013.rs.dns-oarc.net." > > on 9.3. > > > > Looks like "IP Fragments Filtered", but I don't understand — why and > > where?! > > > > I'm using ipfw on both hosts, but I don't have any special rules > > about IP fragments at all! And as these systems are in completely > > different networks, with different uplinks and FreeBSD versions! > > > > IPFW doesn't deal with IP fragment reassembly by default. > > You can add something like the following to the start of the IPFW ruleset > to work around it (one for each NIC): > > $IPFW add reass ip from any to any in recv $NIC0 > $IPFW add reass ip from any to any in recv $NIC1 The ipfw man page says: Usually a simple rule like: # reassemble incoming fragments ipfw add reass all from any to any in is all you need at the beginning of your ruleset. However, I could never make this work. It eats all fragments but the resulting final packet never makes it. I am back to ipfw -q add 1 pass udp from any to $myip frag in recv $ifc as I need it only for UDP. Frag reassembly in pf works well on the other hand... -Andre > ... > > -- > Freddie Cash > fjwc...@gmail.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" -- A fool with a tool is still a fool. ___ 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"
[Differential] [Updated] D1767: Refragment packets after defragmenting them in PF
kristof added a revision: D1815: Evaluate packet size after the firewall had its chance. REVISION DETAIL https://reviews.freebsd.org/D1767 To: kristof Cc: freebsd-net ___ 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"
[Differential] [Updated, 98 lines] D1767: Refragment packets after defragmenting them in PF
kristof updated this revision to Diff 3714. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1767?vs=3621&id=3714 REVISION DETAIL https://reviews.freebsd.org/D1767 AFFECTED FILES sys/net/pfvar.h sys/netpfil/pf/pf.c sys/netpfil/pf/pf.h sys/netpfil/pf/pf_mtag.h sys/netpfil/pf/pf_norm.c To: kristof Cc: freebsd-net ___ 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"
[Differential] [Changed Subscribers] D1815: Evaluate packet size after the firewall had its chance
kristof added a subscriber: freebsd-net. REVISION DETAIL https://reviews.freebsd.org/D1815 To: kristof Cc: freebsd-net ___ 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"
[Differential] [Changed Subscribers] D1815: Evaluate packet size after the firewall had its chance
ae added a subscriber: ae. ae added a comment. Since you are in ip6_forward(), this means ip6_input() has already checked this packet and PFIL had a chance to handle this packet. IPv6 router should not do reassembling fragmented packets and do new fragmentation of them, but if you want, I think your packet filter should track these fragments on input. How do you tested this patch? REVISION DETAIL https://reviews.freebsd.org/D1815 To: kristof Cc: ae, freebsd-net ___ 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"
