Re: Announce IPv6 prefix without being IPv6 gateway?
On 23.04.2017 23:48, Alarig Le Lay wrote: >> I have Point-to-Point Ethernet connection one end of which FreeBSD 11, an >> other end is Windows. It is, really, patch-cord between tow systems, not a >> some tunnel, but physical Ethernet cards. >> >> I want to announce IPv6 Prefix to Windows. FreeBSD system has other live >> interfaces and I don't want any routing performed by this system. >> >> I have manual IPv6 address configuration on FreeBSD and rtadvd running on >> this "P2P" interface. But rtadvd complains: >> >> rtadvd[2663]: non-zero lifetime RA but net.inet6.ip6.forwarding=0. Ignored. >> >> But I don't need IPv6 forwarding! I only want Prefix announcement to avoid >> manual configuration of Windows host and virtual boxes on this host! >> >> Is it possible to achieve such configuration? > > Hi, > > Why don’t you announce your IPv6 range from your router? Because this network haven't router and traffic in this network must be not routed anywhere, it is 10G connection between workstation (Windows) and storage server (FreeBSD). Bith systems in question have another connection to common routable network (1G) with router, announces (with other prefix, of course), etc. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: Announce IPv6 prefix without being IPv6 gateway?
On lun. 24 avr. 14:35:43 2017, Lev Serebryakov wrote: > Because this network haven't router and traffic in this network must be > not routed anywhere, it is 10G connection between workstation (Windows) > and storage server (FreeBSD). Bith systems in question have another > connection to common routable network (1G) with router, announces (with > other prefix, of course), etc. So, use fe80 autoconfigured address between your nodes if you don’t need any router. If you prefer not using link local addresses, you can use a /64 from fc00::/7 but you will have to configure it manually. -- alarig signature.asc Description: PGP signature
[Bug 217637] One TCP connection accepted TWO times
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #82 from Alexandre martins --- I confirm that the workaround works for my test case. I let you develop a more complex solution to avoid data loss and/or TCP re-open on heavy load. Thank you for the patch :) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Avaya
Hi, Are you looking to target companies using Avaya? We provide contacts based in any target vertical and across globe. I have mentioned the information fields that you will receive in the list for each contact within the company. You can also select the industry you would like to target. Information Fields: Name, Title, Email, Phone, Company Name, Physical Address, City, State, Zip Code, Country, Web Address, Employee Size, Revenue Size and Industry. Industry: Healthcare, Telecom, manufacturing, Oil & Gas, Pharmacy, Software, Retail, Real Estate, Construction, Energy, Government, Banking, Legal, Transportation, Wholesale, Agriculture, Business Service, Marketing, Education, Hospitality And Media Internet. Let me know if you are interested and I will get back to you with the counts, sample and pricing. Await for your response. Regards, Paul Kelly Data Consultant To opt out, please reply with Leave Out in the Subject Line. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D10485: Replace dhcp option 150 by 66
kczekirda added reviewers: freebsd-net-list, imp. REVISION DETAIL https://reviews.freebsd.org/D10485 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: kczekirda, bapt, oshogbo, tsoome, sbruno, #network, freebsd-net-list, imp ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D10485: Replace dhcp option 150 by 66
asomers added a comment. Even if this is the correct change to make, the old option must still be supported for backwards compatibility with older PXE servers. Shouldn't there be an accompanying documentation change? How will users know to change their DHCP options? REVISION DETAIL https://reviews.freebsd.org/D10485 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: kczekirda, bapt, oshogbo, tsoome, sbruno, #network, freebsd-net-list, imp Cc: asomers ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D10485: Replace dhcp option 150 by 66
ler added a comment. Can BOTH options be sent with the same value? REVISION DETAIL https://reviews.freebsd.org/D10485 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: kczekirda, bapt, oshogbo, tsoome, sbruno, #network, freebsd-net-list, imp Cc: ler, asomers ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Announce IPv6 prefix without being IPv6 gateway?
At Sun, 23 Apr 2017 22:48:05 +0300, Lev Serebryakov wrote: > rtadvd[2663]: non-zero lifetime RA but net.inet6.ip6.forwarding=0. Ignored. > > But I don't need IPv6 forwarding! I only want Prefix announcement to avoid > manual configuration of Windows host and virtual boxes on this host! > > Is it possible to achieve such configuration? Yes it is. You'll need to set the router lifetime to 0 in rtadvd.conf, e.g. ef0:\ :addr="2001:db8::1000::":prefixlen#64:rltime#0: See also rtadvd.conf(5). -- JINMEI, Tatuya ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxgbe netmap promiscuous mode?
On 04/19/2017 08:31, Joe Jones wrote:
Hi Navdeep,
I already got rid of the hw.cxgbe.num_vis line in loader.conf when I
rebooted this morning.
dev.t5nex.0.firmware_version: 1.15.37.0
I tried this exact firmware and was able to reproduce the problem. This
appears to be a firmware bug that has already been fixed in the 1.16.x
firmware available in 10-STABLE.
Regards,
Navdeep
On 19/04/17 15:37, Navdeep Parhar wrote:
What is the firmware version?
# sysctl dev.t5nex.0.firmware_version
I'll try to repeat the experiment with a T520-SO with the firmware that
you have on your card. Does the card behave this way if the extra VIs
are not created? Can you please try without hw.cxgbe.num_vis in
loader.conf?
Regards,
Navdeep
On Wed, Apr 19, 2017 at 10:29:06AM +0100, Joe Jones wrote:
uname -a
FreeBSD goose2 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11
08:48:40 UTC 2017
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
The card is a 'T520-SO Unified Wire Ethernet Controller'
I ran the following with dtrace running in a separate window
ifconfig cxl1 promisc up ( only see broadcast)
ifconfig cxl1 -promisc
ifconfig cxl1 promisc (now I see traffic)
dtrace output was
[root@goose2 /usr/home/joe]# dtrace -n 'fbt::t4_set_rxmode:entry
{trace(arg4)}'
dtrace: description 'fbt::t4_set_rxmode:entry ' matched 1 probe
CPU IDFUNCTION:NAME
4 61078 t4_set_rxmode:entry 1
7 61078 t4_set_rxmode:entry 0
5 61078 t4_set_rxmode:entry 1
On 19/04/17 01:18, Navdeep Parhar wrote:
On Mon, Apr 17, 2017 at 11:00:38AM +0100, Joe Jones wrote:
Hi Navdeep
running "ifconfig up" and then "ifconfig promisc" works. Running
"ifconfig
promisc" and then "ifconfig up" does not work. Running "ifconfig up
promisc"
together does work. Running "ifconfig promisc up" does not work.
What version of FreeBSD is this? I couldn't reproduce this on head
with
a T6 card. Can you please run this in parallel with your ifconfig
commands, note what dtrace logs in response to what command(s), and
send
the output to me?
# dtrace -n 'fbt::t4_set_rxmode:entry {trace(arg4)}'
The combination that does not work leaves the interface in a state
where it
reports it's self as being in promiscuous mode.
In my experiments the interface did function in promiscuous mode
whether
I did "ifconfig cc0 promisc up" or "ifconfig cc0 up promisc".
Regards,
Navdeep
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D10485: Replace dhcp option 150 by 66
rgrimes added a comment. RFC1048 is obsoleted, first by 1533, then by 2132. Please lets follow current RFC's when seeking information and refering to them. Refering to obsolete RFC's is going to lead to obsolete code. I see at least in the comment of adding vend_end that you refer to RFC2132, it is unclear why you refered to 1048 in the description of the change. RFC2132 names code 66 "TFTP server name". I can not find in the RFC that option 150 is defined. I do find from google searches that this was/is a cisco specific value: "DHCP option 150 provides the IP addresses of a list of TFTP servers. • DHCP option 66 gives the IP address or the hostname of a single TFTP server. Note Cisco IP Phones might also include DHCP option 3 in their requests, which sets the default route. A single request might include both options 150 and 66." This clarifies that it is possible to send both. The code change as it stands is a correction to a use of a non standard DHCP option and should move forward on that, it may be worth making a release notes: yes entry in updating saying we no longer support the cisco specific DHCP option 150, or to implement that option with proper processing (I dont think the current code would actually use a list but I did not verify that.) The old code processed this item as a list of ADDRESSES, which is what cisco says it was. The new code also does this, but option 66 is a NAME, which can probably also contain a dotted quad address, but assuming it is a dotted quad address is a bug. INLINE COMMENTS > bootp.c:444 > + val = strsep(&cp, VEND_INFO_END); > + if ((ipaddr = inet_addr(val)) != INADDR_NONE) > + tftpip.s_addr = ipaddr; Here inet_addr(val) is assuming that val is a dotted quad, the specification does not say that. It says Name. Name in the spec usually means this can be a hostname or a dotted quad. > bootp.h:97 > #define TAG_INTF_MTU ((unsigned char) 26) > +#define TAG_TFTP_SERVER ((unsigned char) 66) > + This should be TAG_TFTP_SERVER_NAME which is what the current RFC calls code 66, making it clearer that this is a name and not necessarily a dotted quad address. REVISION DETAIL https://reviews.freebsd.org/D10485 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: kczekirda, bapt, oshogbo, tsoome, sbruno, #network, freebsd-net-list, imp Cc: rgrimes, garga, ler, asomers ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
