Re: WiGig feature / support?

[Chris H]

On Mon, 19 Mar 2018 16:30:00 -0700 "Adrian Chadd"  said


hi!

Hi! Thanks for the quick reply, Adrian!


There's a lot of work to do for this card. The challenge is it's a
completely different thing that our stack needs to understand /and/ it
also kinda pretends to be a PCIe end point too.

Ah, OK. I was afraid I might find it wasn't supported.


I'd start by looking at what the linux stack/driver does for 11ad.
We'd at least have to add 60GHz channel support. I don't know what
else is required for 11ad as I haven't really looked in a few years.

OK. I'll have a look and see what I can come up with. I'll poke you
when I can come up with anything worth while. BTW I meant what I said
about sending you one of these cards. Lemme know if you're interested.

Thanks again!

--Chris




-adrian



___
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"

WiGig feature / support?

[Chris H]

Apologies in advance, should this have gone to @wireless, or ...
That said; I'm performing some R on an efficient alternative to gigabit
networking w/o cables. To that end; my Atheros (QCA9005) WiGig (7Gbps tri-band) 
half mini-pcie card just arrived, and my target test rig (laptop) will arrive

next week. So I suppose I've sort of put the cart before the horse here. But,
any chance I can pull up this card on FreeBSD? If work still needs to be done,
anything you'd like to point me at? In fact, if need be, I'd be willing to send
one of these cards to someone working on this (@adrian ?). :-)

Anyway, if anyone can further enlighten me on WiGig on FreeBSD. I'd *greatly*
appreciate it. :-)

Thanks!

--Chris


___
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: Questions on iflib

[Chris H]

On Wed, 11 May 2016 11:27:20 -0700 "K. Macy" <km...@freebsd.org> wrote

> On Wed, May 11, 2016 at 7:56 AM, Chris H <bsd-li...@bsdforge.com> wrote:
> > On Tue, 10 May 2016 10:25:24 -0700 hiren panchasara
> > <hi...@strugglingcoder.info> wrote
> >
> >> + Kip, Scott.
> >>
> >> On 05/10/16 at 04:46P, David Somayajulu wrote:
> >> > Hi All,
> >> > I have a couple of questions on iflib :
> >> >
> >> > 1.   Are there plans to incorporate iflib into CURRENT. If yes, will
> >> > it make it into FreeBSD11 release ?
> >>
> >> Yes. The library itself (without any drivers) is being prepared for
> >> committing to CURRENT.
> > This is intended to be optional. Right?
> 
> The name Iflib is short for iflnet library. A driver has to be
> programmed to it. It will always be possible to program directly to
> ifnet, but henceforth it will be frowned upon when not absolutely
> necessary. As iflib will ultimately make the driver more performant
> and more maintainable. As a counterexample, the Chelsio driver has to
> manage multiple ports on a single device and handle synchronization
> with upper level protocols. It's also extremely well optimized
> already. I don't know of any other network driver that can justify
> opting out for one of those reasons, much less both.
> 
> -M
No. Makes perfect sense. I'm afraid I mis-guessed it's intent.
Sorry for the noise, and thanks for taking the time to reply. :)

--Chris

--


___
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: Questions on iflib

[Chris H]

On Tue, 10 May 2016 10:25:24 -0700 hiren panchasara
 wrote

> + Kip, Scott.
> 
> On 05/10/16 at 04:46P, David Somayajulu wrote:
> > Hi All,
> > I have a couple of questions on iflib :
> > 
> > 1.   Are there plans to incorporate iflib into CURRENT. If yes, will it
> > make it into FreeBSD11 release ? 
>
> Yes. The library itself (without any drivers) is being prepared for
> committing to CURRENT.
This is intended to be optional. Right?
> 
> > 
> > 2.   Where can I get the latest patch of iflib for FreeBSD_CURRENT ?
> 
> Kip or Scott may provide more info.
> 
> Cheers,
> Hiren

--Chris


___
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: hello , I have a problem

[Chris H]

On Fri, 15 Jan 2016 17:38:23 +0700 Eugene Grosbein  wrote

> Forwarding to freebsd-net@
> 
> On 15.01.2016 17:29, haku...@yahoo.co.jp wrote:
> > I want to make firewall freebsd 10.1
> > 
> > 
> > 
> > 
> > 
> > but I can't start on pf
> > 
> > 
> > I have inserted that  
> > " # - PF Firewall
> > pf_enable="YES" # Enable PF Firewall
> > #pf_rules="/etc/pf.conf" # Rules definition file for PF
> > #pf_flags=""# Additional flags for pfctl startup
> > pflog_enable="YES"  # Start pflogd(8)
> > #pflog_file="/var/log/pflog" # Where pflogd should store the log file"
> > 
> > 
> > 
> > but still I can't
> > 
> > 
> > 
> > this is etc/rc.conf in my freebsd
> > 
> > 
> > 
> > 
> > What is the problem??
To effectively address your issue. More information is required;
What version, and revision of FreeBSD are you trying this on?
What is the contents of your /etc/pf.conf?
What is the error, or other reason that leads you to believe that pf(4)
isn't / won't run?

Also possibly relevant; did you include pf in your [custom] kern file?

Best wishes.

--Chris


___
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: Network Interface name change

[Chris H]

On Mon, 13 Apr 2015 18:14:09 +0200 (CEST) Raimund Sacherer r...@logitravel.com
wrote

 Hello, 
 
 We have one firewall (out of a cluster) in a very remote area and it displays
 erratic behaviour. On reboot, sometimes it initialises network port 0
 correctly and sometimes it does not.  

 I firmly believe it has to do with the KVM port being active on port 0 and I
 had lot's of troubles with it (working/not working) so it's a gamble if port
 0 can be initialised on reboot or not. And more often then not it doesn't
 come up correctly.  

 When it does not work I get this in the boot log: 
 
 em0: Intel(R) PRO/1000 Network Connection 7.4.2 port 0xf060-0xf07f mem
 0xf7c0-0xf7c1,0xf7c34000-0xf7c34fff irq 20 at device 25.0 on pci0 
 em0: Using an MSI interrupt 
 em0: Setup of Shared code failed 
 device_attach: em0 attach returned 6 
 
 
 
 My real problem is that once this happens the port which should be em1 will
 now be em0 and then all my port assignments don't work anymore. In
 anticipation of this possible error I configured the VLANs on the switches
 accordingly so at least I can get access to the firewall and can work on it,
 but I do not know how I can force e.g. that MAC XX is always em1 (or em2,
 em3) regardless of what the BIOS or the boot process think it should be. 
 
 
 Thank you, 
 Best 
 Ray
Maybe just a shot in the dark; But will rc.conf(5) give it to you
via ifconfig(8)?

TL,DR:

The following options are available:

address
  For the DARPA-Internet family, theaddress is either a host name
  present inthe host name data base, hosts(5), or a DARPA Internet
  address expressed in the Internet standard``dot notation''.
  
  Itis also possible to use the CIDR notation (also known as the
  slash notation) toinclude the netmask.  That is, one can specify
  anaddress like 192.168.0.1/16.
  
  For the ``inet6'' family, it is also possible to specify the pre-
  fix lengthusing the slash notation, like ::1/128.  See the
  prefixlen parameter below for moreinformation.
  
  The link-level (``link'') address is specified as a seriesof
  colon-separated hex digits.  This can be used to e.g., seta new
  MAC address on an ethernetinterface, though the mechanism used
  isnot ethernet-specific.  If the interface is already up when
  this option is used, it will be briefly brought down and then
  brought back up again in order to ensure that the receive filter
  inthe underlying ethernet hardware is properly reprogrammed.

address_family
  Specify the address familywhich affects interpretation of the
  remaining parameters.  Since an interface can receive transmis-
  sions in differingprotocols with different naming schemes, spec-
  ifying theaddress family is recommended.  The address or proto-
  col families currently supported are ``inet'', ``inet6'',
  ``atalk'',``ipx'', and ``link''.  The default if available is
  ``inet'' or otherwise ``link''.  ``ether''and ``lladdr'' are
  synonyms for ``link''.

Can't you lock it down, via ETHER?
Or maybe I don't fully understand what you're asking.

HTH

--Chris
 ___
 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

Re: Zerocopy bpf

[Chris H]

On Thu, 29 Jan 2015 12:25:25 +0100 (CET) el...@sentor.se wrote

 Hi!
 
 q1)
 I assume that libpcap has builtin support for checking if sysctl
 net.bpf.zerocopy_enable is set to 1, and if so uses zerocopy.
 Correct?
 
 q2)
 This should mean that all normal sniffing tools like tcpdump, tshark, 
 ngrep, argus, etc do NOT need any specific options in order to use 
 zerocopy.
 Correct?
 
 q3)
 How do I see if zerocopy is used or not? 'netstat -B' don't tell me 
 much, and the tool 'bpfstat' don't seem to exist any more.
I can't speak from personal experience to the rest. But as to
bpfstat(8); it was merged into netstat(1) ~RELENG_7.

--Chris
 
 q4)
 When activating zerocopy, should I immediately see a performance boost on 
 the machine? (like less drops on a heavily loaded sniffer NIC (running in 
 monitor mode))
 
 /Elof
 ___
 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

Re: Tying down network interfaces

[Chris H]

On Tue, 30 Dec 2014 19:02:30 +0100 Martin Birgmeier la5lb...@aon.at wrote

 Hi,
 
 I have two network interfaces as follows:
 
 sis0: NatSemi DP8381[56] 10/100BaseTX port 0xa400-0xa4ff mem
 0xd580-0xd5800fff irq 9 at device 9.0 on pci0
 sis1: NatSemi DP8381[56] 10/100BaseTX port 0x9400-0x94ff mem
 0xd480-0xd4800fff irq 11 at device 12.0 on pci0
 
 When sis0 breaks down, sis1 gets renumbered as sis0, wreaking havoc
 (mostly on my brains until I figure out which card is actually affected).
 
 How do I tie down these two interfaces so that they always stay as sis0
 and sis1, respectively, regardless of which ones are present in the
 system? - I expect to insert something into /boot/device.hints.
Just for starters, you might simply issue:
ifconfig
Which will dump the values of both NIC's (and other net related)
But once you've done that, you could issue a:
ifconfig sis0 down
then watch the blinking lights to help determine which NIC belongs
to which number. Not extremely elegant, but will at least help
narrow down which NIC, is which.
Then in the end, you can allocate your NIC's out of rc.conf(5).

--Chris

 
 -- Martin
 
 ___
 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

Re: NICs devices switches pshycial place on each boot (SOLVED)

[Chris H]

On Thu, 4 Dec 2014 14:41:11 -0800 Adrian Chadd adr...@freebsd.org wrote

 On 4 December 2014 at 14:24, Martin Hanson greencopperm...@yandex.com
 wrote:  It is worth mentioning that the ONLY reason why this worked is
 because  the vendor has provided a serial number. Most vendors don't and it
  would not have worked then.
 
  devd NEEDS to be able to see device MAC addresses!
 
 I'm surprised it doesn't!
Really? I ran into a situation ~2yrs ago trying to manage
a dongle based IF, in an effort get it to work with the
upstream, that required MAC based authentication. It's
in the list archives, somewhere. :)

 Would you mind filing a PR so we do expose
 that particular bit of data?
I'll be happy to do it, myself, now. I'm going to building
a wireless switch, and will be doing *quite* a bit of work in
this area. So will likely be making contributions, and would
like to be kept in the loop. :)

@Martin, Thank you very much for your diligence, and for
sharing your experience, and *especially* your solution.

@Warren; Thanks for your continued dedication!

--Chris

 
 
 
 -a
 ___
 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

Re: NICs devices switches pshycial place on each boot (SOLVED)

[Chris H]

On Thu, 04 Dec 2014 16:32:04 -0800 Chris H bsd-li...@bsdforge.com wrote

 On Thu, 4 Dec 2014 14:41:11 -0800 Adrian Chadd adr...@freebsd.org wrote
 
  On 4 December 2014 at 14:24, Martin Hanson greencopperm...@yandex.com
  wrote:  It is worth mentioning that the ONLY reason why this worked is
  because  the vendor has provided a serial number. Most vendors don't and
  it  would not have worked then.
  
   devd NEEDS to be able to see device MAC addresses!
  
  I'm surprised it doesn't!
 Really? I ran into a situation ~2yrs ago trying to manage
 a dongle based IF, in an effort get it to work with the
 upstream, that required MAC based authentication. It's
 in the list archives, somewhere. :)
 
  Would you mind filing a PR so we do expose
  that particular bit of data?
 I'll be happy to do it, myself, now.
Ahh looks like Martin got the jump on me:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195692

 I'm going to building
 a wireless switch, and will be doing *quite* a bit of work in
 this area. So will likely be making contributions, and would
 like to be kept in the loop. :)
 
 @Martin, Thank you very much for your diligence, and for
 sharing your experience, and *especially* your solution.
 
 @Warren; Thanks for your continued dedication!
 
 --Chris
 
--Chris
  
  
  
  -a
  ___
  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


___
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: Should I be using ipv6_activate_all_interfaces or ip6addrctl_policy=ipv6_prefer

[Chris H]

 On Wed, Aug 27, 2014 at 11:59:25AM +, Bjoern A. Zeeb wrote:

 On 27 Aug 2014, at 06:31 , Jonathan Price free...@jonathanprice.org wrote:

  On 2014-08-27 01:40, Peter Wemm wrote:
  On Tuesday 26 August 2014 10:40:27 free...@jonathanprice.org wrote:
  Hello,
 
  I am configuring a server with IPv4 and IPv6 addresses and have noticed 
  that
  FreeBSD seems to be preferring IPv4, such as when establishing SSH
  connections.
 
  After reading through /etc/defaults/rc.conf, and later 
  /etc/rc.d/ip6addrctl
  I have come to the conclusion that I have two ways to tell FreeBSD to
  prefer IPv6:
 
  1) Add ipv6_activate_all_interfaces to /etc/rc.conf
  2) Add ip6addrctl_policy=ipv6_prefer to /etc/rc.conf
 
 ...
  However, it does sound like for my purposes it would make more sense to use
 ip6addrctl_policy=?ipv6_prefer as that is more explicitly the feature I 
 want, rather
 than getting it inadvertently through the other knob.

 Yes. Definitively.  I am not sure if it has happened but if IPv6 config is 
 configured
 through rc.conf that setting should be(come) default.


 It does not seem so yet (anymore, it was like that many moons ago). A new
 install of 11-current, with the following in rc.conf:

 #
 hostname=fbsd-11-test
 ifconfig_em0=DHCP
 ifconfig_em0_ipv6=inet6 accept_rtadv
 sshd_enable=YES
 #

 Output of ip6addrctl:

 #
 jhay@fbsd-11-test:~ % ip6addrctl
 Prefix  Prec Label  Use
 ::1/128   50 00
 ::/0  40 1   13
 :::0.0.0.0/96100 40
 2002::/16 30 20
 2001::/32  5 50
 fc00::/7   3130
 ::/96  1 30
 fec0::/10  1110
 3ffe::/16  1120
 jhay@fbsd-11-test:~ %
 #

 telnet to a machine with both ipv6 and ipv4 addresses:

 #
 jhay@fbsd-11-test:~ % telnet dolphin
 Trying 146.64.28.14...
 telnet: connect to address 146.64.28.14: Connection refused
 Trying 2001:4200:7000:3:223:aeff:fea5:ef...
 telnet: connect to address 2001:4200:7000:3:223:aeff:fea5:ef: Connection 
 refused
 telnet: Unable to connect to remote host
 jhay@fbsd-11-test:~ %
 #

 I think if an IPv6 address is configured on a machine, it should prefer ipv6
 addresses. That would match what the rest are doing.
All mine do. As the default, I used the same settings you used above (minus the 
DHCP).
Only difference I can see, is that I use STATIC (IPv4  IPv6), and a default
(IPv4  IPv6) gateway. If I telnet/ftp/ssh to any of my hosts, IPv6 is always
attempted first (opposite of your output above). This was also the case, when
I didn't enter a specific IP in the rc.conf(5). With only the gateway IP address
(IPv4), and an IPv4 address for the I. If I chose
ipv6_activate_all_interfaces=YES
or
xxx_ipv6=inet6 accept_rtadv
I always got the coreect IPv6 address, and connection attempts always began
with IPv6 chosen.

I don't know if any of this helps. But thought at least sharing another
experience might.

Best wishes.

--Chris


 Regards

 John
 --
 John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za
 ___
 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

Re: 6rd and DNS (bind/nsd) on FreeBSD

[Chris H]

 On 6/18/2014 10:12 PM, Chris H wrote:
 FreeBSD doesn't support 6rd.  Ironically, pfSense does.
  
 Are you sure?
 There are even a couple of 6rd ports:
 net/stf-6rd-kmod
 and
 net/u6rd
 or am I to understand that _without_ those ports, FreeBSD doesn't
 support 6rd.

 Yes, if you bring in third-party code you can do 6rd on FreeBSD.  I
 meant that FreeBSD does not have 6rd support in the base like it does
 for 6to4 and 6in4.  There have been patches available for years that add
 6rd feature suppport to if_stf, but for some reason they've never made
 it into FreeBSD despite making into downstream projects.

Ahh. That's what I was afraid you were saying. :/
Well. I've got the source for the CPE, and given all the recent work in arm@
I think it might be time to replace the OS on it, and put FreeBSD on it,
with _real_ IPv6. Or, if I can figure out how to wire tip, and ring
(a POTS line) to USB. Create my own CPE. :)

Thanks for taking the time to reply, Darren.

--Chris


___
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: 6rd and DNS (bind/nsd) on FreeBSD

[Chris H]

 On 19/06/14 05:11, Darren Pilgrim wrote:


 FreeBSD doesn't support 6rd.  Ironically, pfSense does.

 This is not entirely true.  6RD is about establishing a 6to4 tunnel to a
 well-defined tunnel server in your provider's infrastructure, so as long
 as you have the details about the tunnel server's IP and the prefix
 you're assigned, you can easily do it manually (or, better, write a tiny
 script to do it for you).
Yes. I have both.
That's good news. Thanks for the info.

--Chris

 Cheers!

 --

 Massimiliano Stucchi
 ___
 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

6rd and DNS (bind/nsd) on FreeBSD

[Chris H]

Greetings,
 I manage a /29 at $home. While I manage _real_ IPv6 on many networks
at $work. I'm stuck with 6rd at $home. I don't much care for 6rd. It's
still pretty much 6to4. But it's all I have to work with, given the
CPE's limitations. So, as I'm new to it, I'm not quite sure _which_
address to advertise, and listen on, on the DNS.
eg; I'm told I have 6 6rd addresses:
2602:::::::
or
2602:::

but the address returned, has the IPv4 bits packed into it.
So which of the to addresses should be advertised in the zone files.
Should that address also be the one used to listen on?

Apologies for seemingly such a dimwitted question. But even
after reading RFC 5569, I'm still unclear.

Thank you.

--Chris

___
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: 6rd and DNS (bind/nsd) on FreeBSD

[Chris H]

 On 6/18/2014 9:36 AM, Chris H wrote:
 Greetings,
   I manage a /29 at $home. While I manage _real_ IPv6 on many networks
 at $work. I'm stuck with 6rd at $home. I don't much care for 6rd. It's
 still pretty much 6to4. But it's all I have to work with, given the
 CPE's limitations. So, as I'm new to it, I'm not quite sure _which_
 address to advertise, and listen on, on the DNS.
 eg; I'm told I have 6 6rd addresses:
 2602:::::::
 or
 2602:::

 but the address returned, has the IPv4 bits packed into it.
 So which of the to addresses should be advertised in the zone files.
 Should that address also be the one used to listen on?

 Apologies for seemingly such a dimwitted question. But even
 after reading RFC 5569, I'm still unclear.

 FreeBSD doesn't support 6rd.  Ironically, pfSense does.
Are you sure?
There are even a couple of 6rd ports:
net/stf-6rd-kmod
and
net/u6rd
or am I to understand that _without_ those ports, FreeBSD doesn't
support 6rd.

Thanks for the reply.

--Chris
 ___
 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

Re: 6rd and DNS (bind/nsd) on FreeBSD

[Chris H]

 Chris,

 On 6/18/2014 8:11 PM, Mail Delivery System wrote:
 bsd-li...@bsdforge.com: host mx99.ultimatedns.net[209.180.214.225]
 said: 550 5.0.0 SPAM and BULK mail REJECTED (in reply to MAIL FROM
 command)

 You might need to adjust your mail filters. :)
Thanks for the heads up. Appears the IP block yoshi.brtsvcs.net
lives in, was on the list (not because of yoshi.brtsvcs.net).
I'm afraid I was hammered by ~500 spammer/hour. So I got a little
overzealous adding IP blocks. I thought I had cleaned it all up. But
appears I need to go over it again.
Interestingly enough, bluerosetech.com doesn't have any A glue.

Thanks again, and sorry. Nothing personal. :)

--Chris


 On 6/18/2014 9:36 AM, Chris H wrote:
 Greetings, I manage a /29 at $home. While I manage _real_ IPv6 on
 many networks at $work. I'm stuck with 6rd at $home. I don't much
 care for 6rd. It's still pretty much 6to4. But it's all I have to
 work with, given the CPE's limitations. So, as I'm new to it, I'm not
 quite sure _which_ address to advertise, and listen on, on the DNS.
 eg; I'm told I have 6 6rd addresses:
 2602::::::: or 2602:::

 but the address returned, has the IPv4 bits packed into it. So which
 of the to addresses should be advertised in the zone files. Should
 that address also be the one used to listen on?

 Apologies for seemingly such a dimwitted question. But even after
 reading RFC 5569, I'm still unclear.

 Thank you.

 --Chris

 ___
 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

Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31

[Chris H]

 On Mon, Apr 07, 2014 at 09:40:53AM -0700, Chris H wrote:
  On Sun, Apr 06, 2014 at 10:49:27PM -0700, Chris H wrote:
   On Thu, Apr 03, 2014 at 01:18:19PM -0700, Chris H wrote:
On Tue, Apr 01, 2014 at 05:53:51PM -0700, Chris H wrote:
 On Tue, Apr 01, 2014 at 01:40:58PM -0700, Chris H wrote:
  On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote:
  [...]
  miibus0: MII bus on nfe0
  rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0
  rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
  auto, auto-flow
  rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0
  [...]---big-snip--8---
  miibus0: mii_mediachg: can't handle non-zero PHY instance 1
 
  As you can see, it looks much the same. I have no idea what
  I should do to better inform the driver/kernel how to better
  handle it. Or is it the driver, itself?
 
  Thank you again, for your thoughtful response.
 
  --Chris
 
 
  I think the way to fix a phy that responds at all addresses is 
  to set a
  hint in loader.conf masking out the ones that aren't real, 
  like so:
 
   hint.miibus.0.phymask=1
 
  You might be able to set =0x0001 to make it more clear 
  it's a
  bitmask, but I'm not sure of that.

 Thank you very much for the hint. I'll give it a shot.
 Any idea why this is happening? I have 4 other MB's using the 
 Nvidia
 chipset, and the nfe(4) driver. But they don't respond this way.


 If some nfe(4) variants badly behave in probing stage, this should
 be handled by driver.  We already have too many hints and tunables
 and I don't think most users know that.  In addition, adding
 additional NIC may change miibus instance number.

 Could you show me the output of 'kenv | grep smbios'?
Yes, of course.
   
Here it is:
   
smbios.bios.reldate=11/22/2010
smbios.bios.vendor=American Megatrends Inc.
smbios.bios.version=V2.7
smbios.chassis.maker=MSI
smbios.chassis.serial=To Be Filled By O.E.M.
smbios.chassis.tag=To Be Filled By O.E.M.
smbios.chassis.version=2.0
smbios.memory.enabled=2097152
smbios.planar.maker=MSI
smbios.planar.product=K9N6PGM2-V2 (MS-7309)
smbios.planar.serial=To be filled by O.E.M.
smbios.planar.version=2.0
smbios.socket.enabled=1
smbios.socket.populated=1
smbios.system.maker=MSI
smbios.system.product=MS-7309
smbios.system.serial=To Be Filled By O.E.M.
smbios.system.uuid=----406186cd4497
smbios.system.version=2.0
smbios.version=2.6
   
Hope this helps, and thank you for all your time, and trouble.
   
   
Thanks for the info. Try attached patch and let me know how it
works.  Make sure to remove the hint(hint.miibus.0.phymask=1)
set in loader.conf before testing it.
  
   Hello, and thanks for all the attention.
   Sorry for the delay. I chose to perform a dump(8) before attempting
   the KERn rebuild with the patch. But the kernel threw a read error
   message on one of the drives. So I had to sort out the problem on
   the drive before I could complete the dump. Then, of course I had
   to reslice, and format another drive to replace the ailing one,
   before I could perform a restore(8), and start the nfe patch; build
install kernel. Weird; the drive had only a few hours on it.
   Well, anyway. The patch applied cleanly. So I built, and installed
   a new kernel with it. X's out the hint.miibus.0.phymask=0x0001
   in loader.conf(5), and bounced the box. Bad news:
   miibus0: mii_mediachg: can't handle non-zero PHY instance 31
   miibus0: mii_mediachg: can't handle non-zero PHY instance 30
   miibus0: mii_mediachg: can't handle non-zero PHY instance 29
   miibus0: mii_mediachg: can't handle non-zero PHY instance 28
   miibus0: mii_mediachg: can't handle non-zero PHY instance 27
   miibus0: mii_mediachg: can't handle non-zero PHY instance 26
   miibus0: mii_mediachg: can't handle non-zero PHY instance 25
   miibus0: mii_mediachg: can't handle non-zero PHY instance 24
   miibus0: mii_mediachg: can't handle non-zero PHY instance 23
   miibus0: mii_mediachg: can't handle non-zero PHY instance 22
   miibus0: mii_mediachg: can't handle non-zero PHY instance 21
   miibus0: mii_mediachg: can't handle non-zero PHY instance 20
   miibus0: mii_mediachg: can't handle non-zero PHY instance 19
   miibus0: mii_mediachg: can't handle non-zero PHY instance 18
   miibus0: mii_mediachg: can't handle non-zero PHY instance 17
   miibus0: mii_mediachg: can't handle non-zero PHY instance 16
   miibus0: mii_mediachg: can't handle non-zero PHY instance 15
   miibus0: mii_mediachg: can't handle non-zero PHY instance 14
   miibus0: mii_mediachg: can't handle non-zero PHY instance 13
   miibus0: mii_mediachg: can't handle non-zero PHY instance 12
   miibus0: mii_mediachg: can't handle non-zero PHY instance 11
   miibus0: mii_mediachg: can't

Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31

[Chris H]

 On Sun, Apr 06, 2014 at 10:49:27PM -0700, Chris H wrote:
  On Thu, Apr 03, 2014 at 01:18:19PM -0700, Chris H wrote:
   On Tue, Apr 01, 2014 at 05:53:51PM -0700, Chris H wrote:
On Tue, Apr 01, 2014 at 01:40:58PM -0700, Chris H wrote:
 On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote:
 [...]
 miibus0: MII bus on nfe0
 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0
 rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, 
 auto-flow
 rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0
 [...]---big-snip--8---
 miibus0: mii_mediachg: can't handle non-zero PHY instance 1

 As you can see, it looks much the same. I have no idea what
 I should do to better inform the driver/kernel how to better
 handle it. Or is it the driver, itself?

 Thank you again, for your thoughtful response.

 --Chris


 I think the way to fix a phy that responds at all addresses is to 
 set a
 hint in loader.conf masking out the ones that aren't real, like 
 so:

  hint.miibus.0.phymask=1

 You might be able to set =0x0001 to make it more clear it's 
 a
 bitmask, but I'm not sure of that.
   
Thank you very much for the hint. I'll give it a shot.
Any idea why this is happening? I have 4 other MB's using the Nvidia
chipset, and the nfe(4) driver. But they don't respond this way.
   
   
If some nfe(4) variants badly behave in probing stage, this should
be handled by driver.  We already have too many hints and tunables
and I don't think most users know that.  In addition, adding
additional NIC may change miibus instance number.
   
Could you show me the output of 'kenv | grep smbios'?
   Yes, of course.
  
   Here it is:
  
   smbios.bios.reldate=11/22/2010
   smbios.bios.vendor=American Megatrends Inc.
   smbios.bios.version=V2.7
   smbios.chassis.maker=MSI
   smbios.chassis.serial=To Be Filled By O.E.M.
   smbios.chassis.tag=To Be Filled By O.E.M.
   smbios.chassis.version=2.0
   smbios.memory.enabled=2097152
   smbios.planar.maker=MSI
   smbios.planar.product=K9N6PGM2-V2 (MS-7309)
   smbios.planar.serial=To be filled by O.E.M.
   smbios.planar.version=2.0
   smbios.socket.enabled=1
   smbios.socket.populated=1
   smbios.system.maker=MSI
   smbios.system.product=MS-7309
   smbios.system.serial=To Be Filled By O.E.M.
   smbios.system.uuid=----406186cd4497
   smbios.system.version=2.0
   smbios.version=2.6
  
   Hope this helps, and thank you for all your time, and trouble.
  
  
   Thanks for the info. Try attached patch and let me know how it
   works.  Make sure to remove the hint(hint.miibus.0.phymask=1)
   set in loader.conf before testing it.
 
  Hello, and thanks for all the attention.
  Sorry for the delay. I chose to perform a dump(8) before attempting
  the KERn rebuild with the patch. But the kernel threw a read error
  message on one of the drives. So I had to sort out the problem on
  the drive before I could complete the dump. Then, of course I had
  to reslice, and format another drive to replace the ailing one,
  before I could perform a restore(8), and start the nfe patch; build
   install kernel. Weird; the drive had only a few hours on it.
  Well, anyway. The patch applied cleanly. So I built, and installed
  a new kernel with it. X's out the hint.miibus.0.phymask=0x0001
  in loader.conf(5), and bounced the box. Bad news:
  miibus0: mii_mediachg: can't handle non-zero PHY instance 31
  miibus0: mii_mediachg: can't handle non-zero PHY instance 30
  miibus0: mii_mediachg: can't handle non-zero PHY instance 29
  miibus0: mii_mediachg: can't handle non-zero PHY instance 28
  miibus0: mii_mediachg: can't handle non-zero PHY instance 27
  miibus0: mii_mediachg: can't handle non-zero PHY instance 26
  miibus0: mii_mediachg: can't handle non-zero PHY instance 25
  miibus0: mii_mediachg: can't handle non-zero PHY instance 24
  miibus0: mii_mediachg: can't handle non-zero PHY instance 23
  miibus0: mii_mediachg: can't handle non-zero PHY instance 22
  miibus0: mii_mediachg: can't handle non-zero PHY instance 21
  miibus0: mii_mediachg: can't handle non-zero PHY instance 20
  miibus0: mii_mediachg: can't handle non-zero PHY instance 19
  miibus0: mii_mediachg: can't handle non-zero PHY instance 18
  miibus0: mii_mediachg: can't handle non-zero PHY instance 17
  miibus0: mii_mediachg: can't handle non-zero PHY instance 16
  miibus0: mii_mediachg: can't handle non-zero PHY instance 15
  miibus0: mii_mediachg: can't handle non-zero PHY instance 14
  miibus0: mii_mediachg: can't handle non-zero PHY instance 13
  miibus0: mii_mediachg: can't handle non-zero PHY instance 12
  miibus0: mii_mediachg: can't handle non-zero PHY instance 11
  miibus0: mii_mediachg: can't handle non-zero PHY instance 10
  miibus0: mii_mediachg: can't handle non-zero PHY instance 9
  miibus0: mii_mediachg: can't handle non-zero PHY instance 8
  miibus0

Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31

[Chris H]

 On Thu, Apr 03, 2014 at 01:18:19PM -0700, Chris H wrote:
  On Tue, Apr 01, 2014 at 05:53:51PM -0700, Chris H wrote:
   On Tue, Apr 01, 2014 at 01:40:58PM -0700, Chris H wrote:
On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote:
[...]
miibus0: MII bus on nfe0
rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, 
auto-flow
rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0
[...]---big-snip--8---
miibus0: mii_mediachg: can't handle non-zero PHY instance 1
   
As you can see, it looks much the same. I have no idea what
I should do to better inform the driver/kernel how to better
handle it. Or is it the driver, itself?
   
Thank you again, for your thoughtful response.
   
--Chris
   
   
I think the way to fix a phy that responds at all addresses is to 
set a
hint in loader.conf masking out the ones that aren't real, like so:
   
 hint.miibus.0.phymask=1
   
You might be able to set =0x0001 to make it more clear it's a
bitmask, but I'm not sure of that.
  
   Thank you very much for the hint. I'll give it a shot.
   Any idea why this is happening? I have 4 other MB's using the Nvidia
   chipset, and the nfe(4) driver. But they don't respond this way.
  
  
   If some nfe(4) variants badly behave in probing stage, this should
   be handled by driver.  We already have too many hints and tunables
   and I don't think most users know that.  In addition, adding
   additional NIC may change miibus instance number.
  
   Could you show me the output of 'kenv | grep smbios'?
  Yes, of course.
 
  Here it is:
 
  smbios.bios.reldate=11/22/2010
  smbios.bios.vendor=American Megatrends Inc.
  smbios.bios.version=V2.7
  smbios.chassis.maker=MSI
  smbios.chassis.serial=To Be Filled By O.E.M.
  smbios.chassis.tag=To Be Filled By O.E.M.
  smbios.chassis.version=2.0
  smbios.memory.enabled=2097152
  smbios.planar.maker=MSI
  smbios.planar.product=K9N6PGM2-V2 (MS-7309)
  smbios.planar.serial=To be filled by O.E.M.
  smbios.planar.version=2.0
  smbios.socket.enabled=1
  smbios.socket.populated=1
  smbios.system.maker=MSI
  smbios.system.product=MS-7309
  smbios.system.serial=To Be Filled By O.E.M.
  smbios.system.uuid=----406186cd4497
  smbios.system.version=2.0
  smbios.version=2.6
 
  Hope this helps, and thank you for all your time, and trouble.
 
 
  Thanks for the info. Try attached patch and let me know how it
  works.  Make sure to remove the hint(hint.miibus.0.phymask=1)
  set in loader.conf before testing it.

 Hello, and thanks for all the attention.
 Sorry for the delay. I chose to perform a dump(8) before attempting
 the KERn rebuild with the patch. But the kernel threw a read error
 message on one of the drives. So I had to sort out the problem on
 the drive before I could complete the dump. Then, of course I had
 to reslice, and format another drive to replace the ailing one,
 before I could perform a restore(8), and start the nfe patch; build
  install kernel. Weird; the drive had only a few hours on it.
 Well, anyway. The patch applied cleanly. So I built, and installed
 a new kernel with it. X's out the hint.miibus.0.phymask=0x0001
 in loader.conf(5), and bounced the box. Bad news:
 miibus0: mii_mediachg: can't handle non-zero PHY instance 31
 miibus0: mii_mediachg: can't handle non-zero PHY instance 30
 miibus0: mii_mediachg: can't handle non-zero PHY instance 29
 miibus0: mii_mediachg: can't handle non-zero PHY instance 28
 miibus0: mii_mediachg: can't handle non-zero PHY instance 27
 miibus0: mii_mediachg: can't handle non-zero PHY instance 26
 miibus0: mii_mediachg: can't handle non-zero PHY instance 25
 miibus0: mii_mediachg: can't handle non-zero PHY instance 24
 miibus0: mii_mediachg: can't handle non-zero PHY instance 23
 miibus0: mii_mediachg: can't handle non-zero PHY instance 22
 miibus0: mii_mediachg: can't handle non-zero PHY instance 21
 miibus0: mii_mediachg: can't handle non-zero PHY instance 20
 miibus0: mii_mediachg: can't handle non-zero PHY instance 19
 miibus0: mii_mediachg: can't handle non-zero PHY instance 18
 miibus0: mii_mediachg: can't handle non-zero PHY instance 17
 miibus0: mii_mediachg: can't handle non-zero PHY instance 16
 miibus0: mii_mediachg: can't handle non-zero PHY instance 15
 miibus0: mii_mediachg: can't handle non-zero PHY instance 14
 miibus0: mii_mediachg: can't handle non-zero PHY instance 13
 miibus0: mii_mediachg: can't handle non-zero PHY instance 12
 miibus0: mii_mediachg: can't handle non-zero PHY instance 11
 miibus0: mii_mediachg: can't handle non-zero PHY instance 10
 miibus0: mii_mediachg: can't handle non-zero PHY instance 9
 miibus0: mii_mediachg: can't handle non-zero PHY instance 8
 miibus0: mii_mediachg: can't handle non-zero PHY instance 7
 miibus0: mii_mediachg: can't handle non-zero PHY instance 6
 miibus0: mii_mediachg: can't handle non-zero PHY instance 5
 miibus0

Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31

[Chris H]

 On Tue, Apr 01, 2014 at 05:53:51PM -0700, Chris H wrote:
  On Tue, Apr 01, 2014 at 01:40:58PM -0700, Chris H wrote:
   On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote:
   [...]
   miibus0: MII bus on nfe0
   rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0
   rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, 
   auto-flow
   rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0
   [...]---big-snip--8---
   miibus0: mii_mediachg: can't handle non-zero PHY instance 1
  
   As you can see, it looks much the same. I have no idea what
   I should do to better inform the driver/kernel how to better
   handle it. Or is it the driver, itself?
  
   Thank you again, for your thoughtful response.
  
   --Chris
  
  
   I think the way to fix a phy that responds at all addresses is to set a
   hint in loader.conf masking out the ones that aren't real, like so:
  
hint.miibus.0.phymask=1
  
   You might be able to set =0x0001 to make it more clear it's a
   bitmask, but I'm not sure of that.
 
  Thank you very much for the hint. I'll give it a shot.
  Any idea why this is happening? I have 4 other MB's using the Nvidia
  chipset, and the nfe(4) driver. But they don't respond this way.
 
 
  If some nfe(4) variants badly behave in probing stage, this should
  be handled by driver.  We already have too many hints and tunables
  and I don't think most users know that.  In addition, adding
  additional NIC may change miibus instance number.
 
  Could you show me the output of 'kenv | grep smbios'?
 Yes, of course.

 Here it is:

 smbios.bios.reldate=11/22/2010
 smbios.bios.vendor=American Megatrends Inc.
 smbios.bios.version=V2.7
 smbios.chassis.maker=MSI
 smbios.chassis.serial=To Be Filled By O.E.M.
 smbios.chassis.tag=To Be Filled By O.E.M.
 smbios.chassis.version=2.0
 smbios.memory.enabled=2097152
 smbios.planar.maker=MSI
 smbios.planar.product=K9N6PGM2-V2 (MS-7309)
 smbios.planar.serial=To be filled by O.E.M.
 smbios.planar.version=2.0
 smbios.socket.enabled=1
 smbios.socket.populated=1
 smbios.system.maker=MSI
 smbios.system.product=MS-7309
 smbios.system.serial=To Be Filled By O.E.M.
 smbios.system.uuid=----406186cd4497
 smbios.system.version=2.0
 smbios.version=2.6

 Hope this helps, and thank you for all your time, and trouble.


 Thanks for the info. Try attached patch and let me know how it
 works.  Make sure to remove the hint(hint.miibus.0.phymask=1)
 set in loader.conf before testing it.

Hello, and thanks for all the attention.
Sorry for the delay. I chose to perform a dump(8) before attempting
the KERn rebuild with the patch. But the kernel threw a read error
message on one of the drives. So I had to sort out the problem on
the drive before I could complete the dump. Then, of course I had
to reslice, and format another drive to replace the ailing one,
before I could perform a restore(8), and start the nfe patch; build
 install kernel. Weird; the drive had only a few hours on it.
Well, anyway. The patch applied cleanly. So I built, and installed
a new kernel with it. X's out the hint.miibus.0.phymask=0x0001
in loader.conf(5), and bounced the box. Bad news:
miibus0: mii_mediachg: can't handle non-zero PHY instance 31
miibus0: mii_mediachg: can't handle non-zero PHY instance 30
miibus0: mii_mediachg: can't handle non-zero PHY instance 29
miibus0: mii_mediachg: can't handle non-zero PHY instance 28
miibus0: mii_mediachg: can't handle non-zero PHY instance 27
miibus0: mii_mediachg: can't handle non-zero PHY instance 26
miibus0: mii_mediachg: can't handle non-zero PHY instance 25
miibus0: mii_mediachg: can't handle non-zero PHY instance 24
miibus0: mii_mediachg: can't handle non-zero PHY instance 23
miibus0: mii_mediachg: can't handle non-zero PHY instance 22
miibus0: mii_mediachg: can't handle non-zero PHY instance 21
miibus0: mii_mediachg: can't handle non-zero PHY instance 20
miibus0: mii_mediachg: can't handle non-zero PHY instance 19
miibus0: mii_mediachg: can't handle non-zero PHY instance 18
miibus0: mii_mediachg: can't handle non-zero PHY instance 17
miibus0: mii_mediachg: can't handle non-zero PHY instance 16
miibus0: mii_mediachg: can't handle non-zero PHY instance 15
miibus0: mii_mediachg: can't handle non-zero PHY instance 14
miibus0: mii_mediachg: can't handle non-zero PHY instance 13
miibus0: mii_mediachg: can't handle non-zero PHY instance 12
miibus0: mii_mediachg: can't handle non-zero PHY instance 11
miibus0: mii_mediachg: can't handle non-zero PHY instance 10
miibus0: mii_mediachg: can't handle non-zero PHY instance 9
miibus0: mii_mediachg: can't handle non-zero PHY instance 8
miibus0: mii_mediachg: can't handle non-zero PHY instance 7
miibus0: mii_mediachg: can't handle non-zero PHY instance 6
miibus0: mii_mediachg: can't handle non-zero PHY instance 5
miibus0: mii_mediachg: can't handle non-zero PHY instance 4
miibus0: mii_mediachg: can't handle non-zero PHY instance 3
miibus0: mii_mediachg: can't handle non-zero PHY instance 2
miibus0

Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31

[Chris H]

 On Mon, Mar 31, 2014 at 07:57:28AM -0700, Chris H wrote:
  On Sun, Mar 30, 2014 at 01:12:20PM -0700, chr...@ultimatedns.net wrote:
  Greetings,
   I'm not sure whether this best belonged on net@, or stable@
  so I'm using both. :)
  I'm testing both releng_9, and MB, and I encountered a new
  message I don't usually see using the nfe(4) driver:
 
  miibus0: mii_mediachg: can't handle non-zero PHY instance 1
  ...
  miibus0: mii_mediachg: can't handle non-zero PHY instance 31
 
  Truncated for brevity (31 lines in total; 1-31). I don't know
  how interpret this. An issue with my version of the driver, or
  the hardware itself? This occurred with both GENERIC, as well
  as my custom kernel.
 
  Would you show me the dmesg output?
 Happily:

 Calibrating TSC clock ... TSC clock: 3231132841 Hz
 CPU: AMD Sempron(tm) 140 Processor (3231.13-MHz K8-class CPU)
   Origin = AuthenticAMD  Id = 0x100f62  Family = 0x10  Model = 0x6  
 Stepping = 2
   
 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2
   Features2=0x802009SSE3,MON,CX16,POPCNT
   AMD 
 Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!
   AMD 
 Features2=0x37fdLAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT

 [...]

 nfe0: NVIDIA nForce MCP61 Networking Adapter port 0xe480-0xe487 mem
 0xdff7d000-0xdff7dfff
 irq 20 at device 7.0 on pci0
 nfe0: attempting to allocate 8 MSI vectors (8 supported)
 msi: routing MSI IRQ 257 to local APIC 0 vector 56
 msi: routing MSI IRQ 258 to local APIC 0 vector 57
 msi: routing MSI IRQ 259 to local APIC 0 vector 58
 msi: routing MSI IRQ 260 to local APIC 0 vector 59
 msi: routing MSI IRQ 261 to local APIC 0 vector 60
 msi: routing MSI IRQ 262 to local APIC 0 vector 61
 msi: routing MSI IRQ 263 to local APIC 0 vector 62
 msi: routing MSI IRQ 264 to local APIC 0 vector 63
 nfe0: using IRQs 257-264 for MSI
 nfe0: Using 8 MSI messages
 miibus0: MII bus on nfe0
 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0
 rlphy0: OUI 0x04, model 0x0020, rev. 1
 rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
 rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0
 rlphy1: OUI 0x04, model 0x0020, rev. 1
 rlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow

 [...]

 rlphy30: RTL8201L 10/100 media interface PHY 30 on miibus0
 rlphy30: OUI 0x04, model 0x0020, rev. 1
 rlphy30:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
 rlphy31: RTL8201L 10/100 media interface PHY 31 on miibus0
 rlphy31: OUI 0x04, model 0x0020, rev. 1
 rlphy31:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
 nfe0: bpf attached
 nfe0: Ethernet address: 40:61:86:cd:44:97

 mii(4) thinks it has 32 PHYs and this is the reason why mii(4)
 complains.  Due to unknown reason, accessing PHY registers in
 device probe stage got valid response which in turn makes the
 driver think there are 32 PHYs.  Did you ever see this this kind of
 message on old FreeBSD release? Or could you try cold-boot and see
 whether it makes any difference?
Greetings, and thank you for taking the time to respond.
I downloaded, and booted to the 8.4-memstick. Droped to FIXIT, and
captured the dmesg(8) output. I don't know how much of it you need,
so I am including it all:

Table 'FACP' at 0x6ffa0200
Table 'APIC' at 0x6ffa0390
APIC: Found table at 0x6ffa0390
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 129 ACPI ID 2: disabled
MADT: Found CPU APIC ID 130 ACPI ID 3: disabled
MADT: Found CPU APIC ID 131 ACPI ID 4: disabled
MADT: Found CPU APIC ID 132 ACPI ID 5: disabled
MADT: Found CPU APIC ID 133 ACPI ID 6: disabled
Copyright (c) 1992-2013 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 8.4-RELEASE #0 r251259: Sun Jun  2 21:26:57 UTC 2013
r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
gcc version 4.2.1 20070831 patched [FreeBSD]
Preloaded elf kernel /boot/kernel/kernel at 0x8146d000.
Preloaded mfs_root /boot/mfsroot at 0x8146d200.
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 3231096596 Hz
CPU: AMD Sempron(tm) 140 Processor (3231.10-MHz K8-class CPU)
  Origin = AuthenticAMD  Id = 0x100f62  Family = 10  Model = 6  Stepping = 2
  
Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2
  Features2=0x802009SSE3,MON,CX16,POPCNT
  AMD 
Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!
  AMD 
Features2=0x37fdLAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT
  TSC: P-state invariant
L1 2MB data TLB: 48 entries, fully associative
L1 2MB instruction TLB: 16 entries, fully

Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31

[Chris H]

 On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote:
 [...]
 miibus0: MII bus on nfe0
 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0
 rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
 rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0
 [...]---big-snip--8---
 miibus0: mii_mediachg: can't handle non-zero PHY instance 1

 As you can see, it looks much the same. I have no idea what
 I should do to better inform the driver/kernel how to better
 handle it. Or is it the driver, itself?

 Thank you again, for your thoughtful response.

 --Chris


 I think the way to fix a phy that responds at all addresses is to set a
 hint in loader.conf masking out the ones that aren't real, like so:

  hint.miibus.0.phymask=1

 You might be able to set =0x0001 to make it more clear it's a
 bitmask, but I'm not sure of that.

Thank you very much for the hint. I'll give it a shot.
Any idea why this is happening? I have 4 other MB's using the Nvidia
chipset, and the nfe(4) driver. But they don't respond this way.

Thank you again, for your helpful reply.
I'll report back with my findings.

--Chris


 -- Ian




___
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: miibus0: mii_mediachg: can't handle non-zero PHY instance 31

[Chris H]

 On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote:
 [...]
 miibus0: MII bus on nfe0
 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0
 rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
 rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0
 [...]---big-snip--8---
 miibus0: mii_mediachg: can't handle non-zero PHY instance 1

 As you can see, it looks much the same. I have no idea what
 I should do to better inform the driver/kernel how to better
 handle it. Or is it the driver, itself?

 Thank you again, for your thoughtful response.

 --Chris


 I think the way to fix a phy that responds at all addresses is to set a
 hint in loader.conf masking out the ones that aren't real, like so:

  hint.miibus.0.phymask=1

 You might be able to set =0x0001 to make it more clear it's a
 bitmask, but I'm not sure of that.

 Thank you very much for the hint. I'll give it a shot.
 Any idea why this is happening? I have 4 other MB's using the Nvidia
 chipset, and the nfe(4) driver. But they don't respond this way.

 Thank you again, for your helpful reply.
 I'll report back with my findings.

 --Chris

OK. As promised. Here's the results.
For the record, I used the following in loader.conf(5):

hint.miibus.0.phymask=0x0001

Here's the output (minus the sound card stuff):

Syncing disks, vnodes remaining...8 8 4 4 1 0 1 1 1 1 0 0 done
All buffers synced.
Table 'FACP' at 0x6ffa0200
Table 'APIC' at 0x6ffa0390
APIC: Found table at 0x6ffa0390
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 129 ACPI ID 2: disabled
MADT: Found CPU APIC ID 130 ACPI ID 3: disabled
MADT: Found CPU APIC ID 131 ACPI ID 4: disabled
MADT: Found CPU APIC ID 132 ACPI ID 5: disabled
MADT: Found CPU APIC ID 133 ACPI ID 6: disabled
Copyright (c) 1992-2014 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 9.2-STABLE #0 r263756: Wed Mar 26 11:28:10 PDT 2014
root@demon0:/usr/obj/usr/src/sys/DEMON0 amd64
gcc version 4.2.1 20070831 patched [FreeBSD]
Preloaded elf kernel /boot/kernel/kernel at 0x81d9d000.
Preloaded elf obj module /boot/kernel/linux.ko at 0x81d9d200.
Preloaded elf obj module /boot/modules/nvidia.ko at 0x81d9db28.
Calibrating TSC clock ... TSC clock: 3231148565 Hz
CPU: AMD Sempron(tm) 140 Processor (3231.15-MHz K8-class CPU)
  Origin = AuthenticAMD  Id = 0x100f62  Family = 0x10  Model = 0x6  Stepping 
= 2
  
Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2
  Features2=0x802009SSE3,MON,CX16,POPCNT
  AMD 
Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!
  AMD 
Features2=0x37fdLAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT
  TSC: P-state invariant
L1 2MB data TLB: 48 entries, fully associative
L1 2MB instruction TLB: 16 entries, fully associative
L1 4KB data TLB: 48 entries, fully associative
L1 4KB instruction TLB: 32 entries, fully associative
L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L2 2MB data TLB: 128 entries, 2-way associative
L2 2MB instruction TLB: 0 entries, 2-way associative
L2 4KB data TLB: 512 entries, 4-way associative
L2 4KB instruction TLB: 512 entries, 4-way associative
L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative
real memory  = 2147483648 (2048 MB)
Physical memory chunk(s):
0x0001 - 0x0009bfff, 573440 bytes (140 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x01dcc000 - 0x6cab2fff, 1791913984 bytes (437479 pages)
avail memory = 1777266688 (1694 MB)
INTR: Adding local APIC 0 as a target
Event timer LAPIC quality 400
ACPI APIC Table: 7309MS A7309200
x86bios:  IVT 0x00-0x0004ff at 0xfe00
x86bios: SSEG 0x098000-0x098fff at 0xff8000226000
x86bios: EBDA 0x09f000-0x09 at 0xfe09f000
x86bios:  ROM 0x0a-0x0fefff at 0xfe0a
APIC: CPU 0 has ACPI ID 1
ULE: setup cpu 0
ACPI: RSDP 0xfaab0 00014 (v00 ACPIAM)
ACPI: RSDT 0x6ffa 00048 (v01 7309MS A7309200 20101122 MSFT 0097)
ACPI: FACP 0x6ffa0200 00084 (v01 7309MS A7309200 20101122 MSFT 0097)
ACPI: DSDT 0x6ffa04b0 0503B (v01  A7309 A7309200 0200 INTL 20051117)
ACPI: FACS 0x6ffae000 00040
ACPI: APIC 0x6ffa0390 00090 (v01 7309MS A7309200 20101122 MSFT 0097)
ACPI: MCFG 0x6ffa0420 0003C (v01 7309MS OEMMCFG  20101122 MSFT 0097)
ACPI: WDRT 0x6ffa0460 00047 (v01 7309MS NV-WDRT  20101122 MSFT 0097)
ACPI: OEMB 0x6ffae040 00072 (v01 7309MS A7309200 20101122 MSFT 0097)
ACPI: SRAT 0x6ffaa4b0 00090 (v03 AMDFAM_F_10 0002 AMD  0001)
ACPI: MSCT 0x6ffaa540 0004E (v01 A M I  OEMBOARD 0001

Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31

[Chris H]

 On Tue, Apr 01, 2014 at 01:40:58PM -0700, Chris H wrote:
  On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote:
  [...]
  miibus0: MII bus on nfe0
  rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0
  rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
  rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0
  [...]---big-snip--8---
  miibus0: mii_mediachg: can't handle non-zero PHY instance 1
 
  As you can see, it looks much the same. I have no idea what
  I should do to better inform the driver/kernel how to better
  handle it. Or is it the driver, itself?
 
  Thank you again, for your thoughtful response.
 
  --Chris
 
 
  I think the way to fix a phy that responds at all addresses is to set a
  hint in loader.conf masking out the ones that aren't real, like so:
 
   hint.miibus.0.phymask=1
 
  You might be able to set =0x0001 to make it more clear it's a
  bitmask, but I'm not sure of that.

 Thank you very much for the hint. I'll give it a shot.
 Any idea why this is happening? I have 4 other MB's using the Nvidia
 chipset, and the nfe(4) driver. But they don't respond this way.


 If some nfe(4) variants badly behave in probing stage, this should
 be handled by driver.  We already have too many hints and tunables
 and I don't think most users know that.  In addition, adding
 additional NIC may change miibus instance number.

 Could you show me the output of 'kenv | grep smbios'?
Yes, of course.

Here it is:

smbios.bios.reldate=11/22/2010
smbios.bios.vendor=American Megatrends Inc.
smbios.bios.version=V2.7
smbios.chassis.maker=MSI
smbios.chassis.serial=To Be Filled By O.E.M.
smbios.chassis.tag=To Be Filled By O.E.M.
smbios.chassis.version=2.0
smbios.memory.enabled=2097152
smbios.planar.maker=MSI
smbios.planar.product=K9N6PGM2-V2 (MS-7309)
smbios.planar.serial=To be filled by O.E.M.
smbios.planar.version=2.0
smbios.socket.enabled=1
smbios.socket.populated=1
smbios.system.maker=MSI
smbios.system.product=MS-7309
smbios.system.serial=To Be Filled By O.E.M.
smbios.system.uuid=----406186cd4497
smbios.system.version=2.0
smbios.version=2.6

Hope this helps, and thank you for all your time, and trouble.

--Chris



___
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: how calculate the number of ip addresses in a range?

[Chris H]

 hello guys,

 i have a question about ip addresses. i know my question is not related to
 freebsd but i googled a lot and found nothing useful and don't know where i
 should ask my question.

 i want to know how can i calculate the number of ip addresses in a range?
 for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip
 addresses are available in this range? is there any formula to calculate
 the number of ip addresses for any range?

 i'm confusing about it. please help me to clear my mind.
 thanks in advance,
 SAM
Aside from many ports available in the ports/net* categories that provide 
calculators, and
such. You can use an online version @: http://ultimatedns.net/netcalc

HTH

--chris

 ___
 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

Re: re0 not working at boot on -CURRENT

[Chris H]

 On 07/10/13 19:47, Guido Falsi wrote:
 On 07/10/13 09:04, Yonghyeon PYUN wrote:
 On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote:
 Hi,

 I have a PC with an integrate re ethernet interface, pciconf identifies
 it like this:

 re0@pci0:3:0:0: class=0x02 card=0x11c01734 chip=0x816810ec rev=0x07
 hdr=0x00

 I'm running FreeBSD current r252261.

 As stated in the subject after boot the interface does not work
 correctly.

 Using tcpdump on another host I noticed that packets (ICMP echo requests
 for example) do get sent, and replies generated by the other host, but
 the kernel does not seem to see them. Except that every now and then
 some packet does get to the system.

 I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on
 from a ping which has been running for some time. Just about one every
 twenty. Some pattern is showing up.

 this is the output of ifconfig re0 after boot:

 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
 1500

 options=8209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE

  ether 00:19:99:f8:d3:0b
  inet 172.24.42.13 netmask 0xff00 broadcast 172.24.42.255
  inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2
  nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
  media: Ethernet autoselect (100baseTX full-duplex)
  status: active

 If I just touch any interface flag with ifconfig, anyone, tso, -txcsum
 -rxcsum, it starts working flawlessly. It keeps working also if I
 perform the opposite operation with ifconfig afterwards, so it is not
 the flag itself fixing it.

 This is an ifconfig after performing this exercise(it's the same, since
 I disabled txcsum and reactivated it in this instance):

 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
 1500

 options=8209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE

  ether 00:19:99:f8:d3:0b
  inet 172.24.42.13 netmask 0xff00 broadcast 172.24.42.255
  inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2
  nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
  media: Ethernet autoselect (100baseTX full-duplex)
  status: active

 I don't know much about FreeBSD network drivers so i can't make theories
 about this. I hope someone has an idea what the problem could be.

 I'm available for any further information needed, test, experiment and
 so on.

 Could you show me dmesg output(re(4) and rgephy(4) only)?

 re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port
 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf210-0xf2103fff irq 17 at
 device 0.0 on pci3
 re0: Using 1 MSI-X message
 re0: turning off MSI enable bit.
 re0: Chip rev. 0x2c80
 re0: MAC rev. 0x
 re0: Ethernet address: 00:19:99:f8:d3:0b
 miibus0: MII bus on re0
 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface 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

 Also, I'm loading this as a module, but, for as much as I know, this
 should not make any difference.


 Did it ever work or you see the issue only on CURRENT?

 Never worked on this machine (I own it since the last days of February).

 I only installed current on it. If needed I can find time to test a
 recent 9.x snapshot on it.

 Sorry for the delay.

 I tested with a 9.2 PRERELEASE snapshot and it shows the same behavior
 it shows on CURRENT.

 Any further tests or things I can do to help diagnose this problem?

 --
 Guido Falsi m...@madpilot.net
Greetings,
 I may be just groping here, but I notice in your ifconfig(8) output:
  nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
^^
While you may have explicitly disabled it; my output (also re0) reads:
nd6 options=3PERFORMNUD,ACCEPT_RTADV

Just saying, cause I'm not experiencing your issue(s), and mine is also an 
onboard
NIC.

--chris

 ___
 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

Re: re0 not working at boot on -CURRENT

[Chris H]

 On 07/10/13 19:47, Guido Falsi wrote:
 On 07/10/13 09:04, Yonghyeon PYUN wrote:
 On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote:
 Hi,

 I have a PC with an integrate re ethernet interface, pciconf identifies
 it like this:

 re0@pci0:3:0:0: class=0x02 card=0x11c01734 chip=0x816810ec rev=0x07
 hdr=0x00

 I'm running FreeBSD current r252261.

 As stated in the subject after boot the interface does not work
 correctly.

 Using tcpdump on another host I noticed that packets (ICMP echo requests
 for example) do get sent, and replies generated by the other host, but
 the kernel does not seem to see them. Except that every now and then
 some packet does get to the system.

 I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on
 from a ping which has been running for some time. Just about one every
 twenty. Some pattern is showing up.

 this is the output of ifconfig re0 after boot:

 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
 1500

 options=8209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE

  ether 00:19:99:f8:d3:0b
  inet 172.24.42.13 netmask 0xff00 broadcast 172.24.42.255
  inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2
  nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
  media: Ethernet autoselect (100baseTX full-duplex)
  status: active

 If I just touch any interface flag with ifconfig, anyone, tso, -txcsum
 -rxcsum, it starts working flawlessly. It keeps working also if I
 perform the opposite operation with ifconfig afterwards, so it is not
 the flag itself fixing it.

 This is an ifconfig after performing this exercise(it's the same, since
 I disabled txcsum and reactivated it in this instance):

 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
 1500

 options=8209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE

  ether 00:19:99:f8:d3:0b
  inet 172.24.42.13 netmask 0xff00 broadcast 172.24.42.255
  inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2
  nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
  media: Ethernet autoselect (100baseTX full-duplex)
  status: active

 I don't know much about FreeBSD network drivers so i can't make theories
 about this. I hope someone has an idea what the problem could be.

 I'm available for any further information needed, test, experiment and
 so on.

 Could you show me dmesg output(re(4) and rgephy(4) only)?

 re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port
 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf210-0xf2103fff irq 17 at
 device 0.0 on pci3
 re0: Using 1 MSI-X message
 re0: turning off MSI enable bit.
 re0: Chip rev. 0x2c80
 re0: MAC rev. 0x
 re0: Ethernet address: 00:19:99:f8:d3:0b
 miibus0: MII bus on re0
 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface 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

 Also, I'm loading this as a module, but, for as much as I know, this
 should not make any difference.


 Did it ever work or you see the issue only on CURRENT?

 Never worked on this machine (I own it since the last days of February).

 I only installed current on it. If needed I can find time to test a
 recent 9.x snapshot on it.

 Sorry for the delay.

 I tested with a 9.2 PRERELEASE snapshot and it shows the same behavior
 it shows on CURRENT.

 Any further tests or things I can do to help diagnose this problem?

 --
 Guido Falsi m...@madpilot.net
 Greetings,
  I may be just groping here, but I notice in your ifconfig(8) output:
  nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
 ^^
 While you may have explicitly disabled it; my output (also re0) reads:
 nd6 options=3PERFORMNUD,ACCEPT_RTADV

 Just saying, cause I'm not experiencing your issue(s), and mine is also an 
 onboard
 NIC.

 --chris
P.S. There were also recent changes to rc(8) regarding the syntax of ifconfig.

 ___
 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


___
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: MAC cloning available like Linux has?

[Chris H]

Hello Glen, and thank you for your reply.
 On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote:
 ifconfig_ue0=DHCP
 create_args_ue0=ether ##:##:##:##:##:##
 create_args is simply ignored.


 Ignored how?  What commands are you running to verify it works?
 For me, create_args_IFNAME works fine on my firewall.

Unfortunately, it had no affect for me.
The ue0 maintained the same MAC it started with.
Out of desperation, I even tried it in /boot/loader.conf.
One thing I think might be worth noting; I see bge appears
to interrupt the process, as it attaches to ue0. I don't
have the RELENG_9 drive plugged in, as I write this, or
I could paste the message here. Is it possible this is more
an RC(8) problem, than anything else? I notice since 8.2,
the RC(8) seems to have some differences. For example;
it used to be possible to declare:
ifconfig_if#_alias#=ether ##:##:##:##:##:##

But when I attempt to try this now, I receive an error
indicating something about requiring an inet when using ipv4.
but adding an inet 1p,v.4.address stanza to it, causes an error
as well.


 I don't get it. I've tried every imaginable incarnation I
 could possibly conceive. Is it even possible? I had really
 hoped to turn this into a gateway, and while Linux will
 clone the MAC(3). I don't trust it (security wise).
 Is Linux' DHCP more robust than BSD'?! Hard to imagine,
 but I'm completely at a loss.


 I do not think this is DHCP related.  It is more differentiation between
 the two with regards to how interface creation is handled.

Agreed.


 Glen


Thank you again, for taking the time to reply.

--Chris

___
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: MAC cloning available like Linux has?

[Chris H]

Greetings Warren, and thank you for your reply.

 On Fri, 14 Dec 2012, Chris H wrote:

 with: ifconfig_ue0=ether ##:##:##:##:##:##; DHCP
 the ether isn't honored (ignored)

 Remove the semicolon.  I don't know if the order of parameters there
 matters, but think that the rc scripts just look for the presence of
 DHCP.

 This just worked in a VM here.


I'm afraid I didn't have the same experience trying that. :(
Out of curiosity, what version did you use? I used the CD
image of 9.0 I downloaded from freebsd.org yesterday.

Thank you again, for taking the time to respond.

--Chris


___
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: MAC cloning available like Linux has?

[Chris H]

 On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote:
 Hello Glen, and thank you for your reply.
  On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote:
  ifconfig_ue0=DHCP
  create_args_ue0=ether ##:##:##:##:##:##
  create_args is simply ignored.
 
 
  Ignored how?  What commands are you running to verify it works?
  For me, create_args_IFNAME works fine on my firewall.

 Unfortunately, it had no affect for me.
 The ue0 maintained the same MAC it started with.
 Out of desperation, I even tried it in /boot/loader.conf.

 It is not a loader(8) tunable, it is part of the rc(8) system.

 You did not answer the important part of what I asked - how are you
 testing?  Are you rebooting the machine?  Are you using the netif rc
 script?

Ahh. Sorry, my bad. Rebooting.

I have no difficulty issuing:
ifconfig ue0 down
ifconfig ue0 ether ##:##:##:##:##:##
dhclient ue0

This method will always return the expected/desired results.


 Glen


Thanks for the reply.

--Chris


___
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: MAC cloning available like Linux has?

[Chris H]

 Hi,

 Please file a PR for this. I think this (and mac address
Greetings Adrian, and thank you for your reply.

 setup/changing on net80211, similar issues) needs both some better
 documentation/FAQ entries and updates to the rc scripts.

 I think we may want to add an ifconfig_X_ether= to set the L2
 address appropriately for an interface.

 Thanks,



 Adrian

Well, on a hunch regarding RC(8), I blew 9.0 off the drive, and
experimented with installing 8.2. But I think I stumbled onto
something. I don't know (yet) if this will carry over to 9.x yet.
But here's what I discovered:

in rc.conf, adding the following (order is important!), everything
works as expected/desired/anticipated;

--- begin rc,conf --
ifconfig_ue0=ether ##:##:##:##:##:##

ifconfig_ue0_alias0=DHCP

*** or ***

ifconfig_ue0_alias0=inet ip4.add.ress.anticipated netmask kno.wn.net.mask

followed by
defaultrouter=kno.wn.gate.way --applies for static only
--- end rc,conf --

So. It appears this will be the answer. _However_ I can't swear to it
until I spin up  install a (fresh) copy of RELENG_9.
I'll do so, and report back.

Thanks again, for your reply.

--Chris




 On 15 December 2012 10:36, Chris H chris#@1command.com wrote:
 On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote:
 Hello Glen, and thank you for your reply.
  On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote:
  ifconfig_ue0=DHCP
  create_args_ue0=ether ##:##:##:##:##:##
  create_args is simply ignored.
 
 
  Ignored how?  What commands are you running to verify it works?
  For me, create_args_IFNAME works fine on my firewall.

 Unfortunately, it had no affect for me.
 The ue0 maintained the same MAC it started with.
 Out of desperation, I even tried it in /boot/loader.conf.

 It is not a loader(8) tunable, it is part of the rc(8) system.

 You did not answer the important part of what I asked - how are you
 testing?  Are you rebooting the machine?  Are you using the netif rc
 script?

 Ahh. Sorry, my bad. Rebooting.

 I have no difficulty issuing:
 ifconfig ue0 down
 ifconfig ue0 ether ##:##:##:##:##:##
 dhclient ue0

 This method will always return the expected/desired results.


 Glen


 Thanks for the reply.

 --Chris


 ___
 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

Re: MAC cloning available like Linux has?

[Chris H]

Hello Warren, and thank you for your reply.

 On Sat, 15 Dec 2012, Chris H wrote:

 Greetings Warren, and thank you for your reply.

 On Fri, 14 Dec 2012, Chris H wrote:

 with: ifconfig_ue0=ether ##:##:##:##:##:##; DHCP
 the ether isn't honored (ignored)

 Remove the semicolon.  I don't know if the order of parameters there
 matters, but think that the rc scripts just look for the presence of
 DHCP.

 This just worked in a VM here.


 I'm afraid I didn't have the same experience trying that. :(
 Out of curiosity, what version did you use? I used the CD
 image of 9.0 I downloaded from freebsd.org yesterday.

 9.0-RELEASE.  The string I have in rc.conf:

ifconfig_le0=ether 80:01:01:01:01:01 DHCP

 dhclient runs, and the MAC address is set to that according to ifconfig
 output.

 Is it possible that USB Ethernet adapters (or drivers) don't allow
 changing the MAC address?  Seems silly, but...


Well, as I mentioned in my OP; works perfect in Linux, and also if I
apply it manually at a CLI. But was a no-go via RC(8).

However, I stumbled onto something that seems to work consistently
(see my reply to Adrian's post).

Thanks again, for taking the time to respond.

--Chris

___
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: MAC cloning available like Linux has?

[Chris H]

 Hi,

 Please file a PR for this. I think this (and mac address
 Greetings Adrian, and thank you for your reply.

 setup/changing on net80211, similar issues) needs both some better
 documentation/FAQ entries and updates to the rc scripts.

 I think we may want to add an ifconfig_X_ether= to set the L2
 address appropriately for an interface.

 Thanks,



 Adrian

 Well, on a hunch regarding RC(8), I blew 9.0 off the drive, and
 experimented with installing 8.2. But I think I stumbled onto
 something. I don't know (yet) if this will carry over to 9.x yet.
 But here's what I discovered:

 in rc.conf, adding the following (order is important!), everything
 works as expected/desired/anticipated;

 --- begin rc,conf 
 --
 ifconfig_ue0=ether ##:##:##:##:##:##

 ifconfig_ue0_alias0=DHCP

 *** or ***

 ifconfig_ue0_alias0=inet ip4.add.ress.anticipated netmask kno.wn.net.mask

 followed by
 defaultrouter=kno.wn.gate.way --applies for static only
 --- end rc,conf --

 So. It appears this will be the answer. _However_ I can't swear to it
 until I spin up  install a (fresh) copy of RELENG_9.
 I'll do so, and report back.

 Thanks again, for your reply.

 --Chris

OK. The results are in --
Using the RC(8) declarations I listed above work not only in RELENG_8,
but also in RELENG_9. I just performed an install from the 9.0 CD I
downloaded from freebsd.org on 12-12-14. Everything (both as STATIC,
and as DHCP) worked as expected/anticipated.

Is this still worth a PR(1)?

Best wishes, and thanks again, to everyone that took the time to help!

--Chris





 On 15 December 2012 10:36, Chris H chris#@1command.com wrote:
 On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote:
 Hello Glen, and thank you for your reply.
  On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote:
  ifconfig_ue0=DHCP
  create_args_ue0=ether ##:##:##:##:##:##
  create_args is simply ignored.
 
 
  Ignored how?  What commands are you running to verify it works?
  For me, create_args_IFNAME works fine on my firewall.

 Unfortunately, it had no affect for me.
 The ue0 maintained the same MAC it started with.
 Out of desperation, I even tried it in /boot/loader.conf.

 It is not a loader(8) tunable, it is part of the rc(8) system.

 You did not answer the important part of what I asked - how are you
 testing?  Are you rebooting the machine?  Are you using the netif rc
 script?

 Ahh. Sorry, my bad. Rebooting.

 I have no difficulty issuing:
 ifconfig ue0 down
 ifconfig ue0 ether ##:##:##:##:##:##
 dhclient ue0

 This method will always return the expected/desired results.


 Glen


 Thanks for the reply.

 --Chris


 ___
 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


___
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: MAC cloning available like Linux has? [SOLVED]

[Chris H]

 Hi,

 Please file a PR for this. I think this (and mac address
 Greetings Adrian, and thank you for your reply.

 setup/changing on net80211, similar issues) needs both some better
 documentation/FAQ entries and updates to the rc scripts.

 I think we may want to add an ifconfig_X_ether= to set the L2
 address appropriately for an interface.

 Thanks,



 Adrian

 Well, on a hunch regarding RC(8), I blew 9.0 off the drive, and
 experimented with installing 8.2. But I think I stumbled onto
 something. I don't know (yet) if this will carry over to 9.x yet.
 But here's what I discovered:

 in rc.conf, adding the following (order is important!), everything
 works as expected/desired/anticipated;

 --- begin rc,conf 
 --
 ifconfig_ue0=ether ##:##:##:##:##:##

 ifconfig_ue0_alias0=DHCP

 *** or ***

 ifconfig_ue0_alias0=inet ip4.add.ress.anticipated netmask kno.wn.net.mask

 followed by
 defaultrouter=kno.wn.gate.way --applies for static only
 --- end rc,conf --

 So. It appears this will be the answer. _However_ I can't swear to it
 until I spin up  install a (fresh) copy of RELENG_9.
 I'll do so, and report back.

 Thanks again, for your reply.

 --Chris

OK. The results are in --
Using the RC(8) declarations I listed above work not only in RELENG_8,
but also in RELENG_9. I just performed an install from the 9.0 CD I
downloaded from freebsd.org on 12-12-14. Everything (both as STATIC,
and as DHCP) worked as expected/anticipated.

Is this still worth a PR(1)?

Best wishes, and thanks again, to everyone that took the time to help!

--Chris





 On 15 December 2012 10:36, Chris H chris#@1command.com wrote:
 On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote:
 Hello Glen, and thank you for your reply.
  On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote:
  ifconfig_ue0=DHCP
  create_args_ue0=ether ##:##:##:##:##:##
  create_args is simply ignored.
 
 
  Ignored how?  What commands are you running to verify it works?
  For me, create_args_IFNAME works fine on my firewall.

 Unfortunately, it had no affect for me.
 The ue0 maintained the same MAC it started with.
 Out of desperation, I even tried it in /boot/loader.conf.

 It is not a loader(8) tunable, it is part of the rc(8) system.

 You did not answer the important part of what I asked - how are you
 testing?  Are you rebooting the machine?  Are you using the netif rc
 script?

 Ahh. Sorry, my bad. Rebooting.

 I have no difficulty issuing:
 ifconfig ue0 down
 ifconfig ue0 ether ##:##:##:##:##:##
 dhclient ue0

 This method will always return the expected/desired results.


 Glen


 Thanks for the reply.

 --Chris


 ___
 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


___
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: MAC cloning available like Linux has?

[Chris H]

 Yes, please file a PR so that the documentation gets updated to reflect this.

 You can't be the only person who wishes to do this.

 As I said, I think it's worth extended rc.conf to have a specific
 ether field for ifconfig, so any device-specific weird crap
 (especially when creating cloned devices) can be done at the right
 point before the interface is brought up.

 Thanks,



 Adrian

Done! Sent it about 45 minutes ago. :)

Thanks again, to all who took the time to help me through this.

--Chris



 On 15 December 2012 14:11, Chris H chris#@1command.com wrote:
 Hi,

 Please file a PR for this. I think this (and mac address
 Greetings Adrian, and thank you for your reply.

 setup/changing on net80211, similar issues) needs both some better
 documentation/FAQ entries and updates to the rc scripts.

 I think we may want to add an ifconfig_X_ether= to set the L2
 address appropriately for an interface.

 Thanks,



 Adrian

 Well, on a hunch regarding RC(8), I blew 9.0 off the drive, and
 experimented with installing 8.2. But I think I stumbled onto
 something. I don't know (yet) if this will carry over to 9.x yet.
 But here's what I discovered:

 in rc.conf, adding the following (order is important!), everything
 works as expected/desired/anticipated;

 --- begin rc,conf 
 --
 ifconfig_ue0=ether ##:##:##:##:##:##

 ifconfig_ue0_alias0=DHCP

 *** or ***

 ifconfig_ue0_alias0=inet ip4.add.ress.anticipated netmask kno.wn.net.mask

 followed by
 defaultrouter=kno.wn.gate.way --applies for static only
 --- end rc,conf 
 --

 So. It appears this will be the answer. _However_ I can't swear to it
 until I spin up  install a (fresh) copy of RELENG_9.
 I'll do so, and report back.

 Thanks again, for your reply.

 --Chris

 OK. The results are in --
 Using the RC(8) declarations I listed above work not only in RELENG_8,
 but also in RELENG_9. I just performed an install from the 9.0 CD I
 downloaded from freebsd.org on 12-12-14. Everything (both as STATIC,
 and as DHCP) worked as expected/anticipated.

 Is this still worth a PR(1)?

 Best wishes, and thanks again, to everyone that took the time to help!

 --Chris





 On 15 December 2012 10:36, Chris H chris#@1command.com wrote:
 On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote:
 Hello Glen, and thank you for your reply.
  On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote:
  ifconfig_ue0=DHCP
  create_args_ue0=ether ##:##:##:##:##:##
  create_args is simply ignored.
 
 
  Ignored how?  What commands are you running to verify it works?
  For me, create_args_IFNAME works fine on my firewall.

 Unfortunately, it had no affect for me.
 The ue0 maintained the same MAC it started with.
 Out of desperation, I even tried it in /boot/loader.conf.

 It is not a loader(8) tunable, it is part of the rc(8) system.

 You did not answer the important part of what I asked - how are you
 testing?  Are you rebooting the machine?  Are you using the netif rc
 script?

 Ahh. Sorry, my bad. Rebooting.

 I have no difficulty issuing:
 ifconfig ue0 down
 ifconfig ue0 ether ##:##:##:##:##:##
 dhclient ue0

 This method will always return the expected/desired results.


 Glen


 Thanks for the reply.

 --Chris


 ___
 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




___
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: MAC cloning available like Linux has?

[Chris H]

 On Sat, 15 Dec 2012 12:51:11 -0800, Chris H wrote:

   in rc.conf, adding the following (order is important!), everything
   works as expected/desired/anticipated;
  
   --- begin rc,conf 
 --
   ifconfig_ue0=ether ##:##:##:##:##:##
  
   ifconfig_ue0_alias0=DHCP
  
   *** or ***
  
   ifconfig_ue0_alias0=inet ip4.add.ress.anticipated netmask kno.wn.net.mask
  
   followed by
   defaultrouter=kno.wn.gate.way --applies for static only
   --- end rc,conf 
 --

 Just one thing that's important to understand: order in rc.conf is only
 important in one regard, that the _last_ assignment for any particular
 variable is the only one that matters.  rc.conf is just an sh script,
 included by '.', and any later assignments override any earlier ones.

 In particular, the order of assignments to any _different_ variables in
 rc.conf is completely irrelevant.

Thanks for taking the time to point that out. Good to know. Will help me
_not_ make unnecessary moves when trying to sort out a problem like this
in the future. :)


 Glad you got it sorted out otherwise.

Me too. :)

--Chris


 cheers, Ian
 ___
 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

MAC cloning available like Linux has?

[Chris H]

Greetings,
 I attempted another BSD install on another piece of hardware the
other day. I'm evaluating a different ISP, and the gateway/router/modem
they provided, has 1 ether, which I currently use on my server, and 1
USB(3) port that I had intended to use with the new install. Problem I
ran into, was that BSD generates random (fake) MAC(3) addresses, when
utilizing the CDCE(4)/ue0. This worked just fine during the install.
But the modem held the MAC(3) generated during the install, and I
now have no idea how to tell BSD to use that MAC(3) when negotiating
with the modem. I had absolutely no difficulty assigning the MAC(3)
address when spinning up several live Linux distro(s) -- they provide
the following:
su
password: ***
ifconfig eth1 down
ifconfig eth0 hw ether ##:##:##:##:##:##
dhclient eth0
blah, blah, blah

And I'm connected.
Couldn't manage that with BSD. What must I do? Is it even possible?
If so, can it be assigned for use on a permanent basis?

Thank you for all your time, and consideration.

--Chris

___
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: MAC cloning available like Linux has?

[Chris H]

 Greetings,
  I attempted another BSD install on another piece of hardware the
 other day. I'm evaluating a different ISP, and the gateway/router/modem
 they provided, has 1 ether, which I currently use on my server, and 1
 USB(3) port that I had intended to use with the new install. Problem I
 ran into, was that BSD generates random (fake) MAC(3) addresses, when
 utilizing the CDCE(4)/ue0. This worked just fine during the install.
 But the modem held the MAC(3) generated during the install, and I
 now have no idea how to tell BSD to use that MAC(3) when negotiating
 with the modem. I had absolutely no difficulty assigning the MAC(3)
 address when spinning up several live Linux distro(s) -- they provide
 the following:
 su
 password: ***
 ifconfig eth1 down
 ifconfig eth0 hw ether ##:##:##:##:##:##
 dhclient eth0
 blah, blah, blah
EDIT
those _should_ have all read eth1 in the session quoted above.
Sorry.

 And I'm connected.
 Couldn't manage that with BSD. What must I do? Is it even possible?
 If so, can it be assigned for use on a permanent basis?

 Thank you for all your time, and consideration.

 --Chris

 ___
 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

Re: MAC cloning available like Linux has?

[Chris H]

 On Fri, Dec 14, 2012 at 12:11 PM, Chris H chris#@1command.com wrote:

  Greetings,
   I attempted another BSD install on another piece of hardware the
  other day. I'm evaluating a different ISP, and the gateway/router/modem
  they provided, has 1 ether, which I currently use on my server, and 1
  USB(3) port that I had intended to use with the new install. Problem I
  ran into, was that BSD generates random (fake) MAC(3) addresses, when
  utilizing the CDCE(4)/ue0. This worked just fine during the install.
  But the modem held the MAC(3) generated during the install, and I
  now have no idea how to tell BSD to use that MAC(3) when negotiating
  with the modem. I had absolutely no difficulty assigning the MAC(3)
  address when spinning up several live Linux distro(s) -- they provide
  the following:
  su
  password: ***
  ifconfig eth1 down
  ifconfig eth0 hw ether ##:##:##:##:##:##
  dhclient eth0
  blah, blah, blah
 EDIT
 those _should_ have all read eth1 in the session quoted above.
 Sorry.
 
  And I'm connected.
  Couldn't manage that with BSD. What must I do? Is it even possible?
  If so, can it be assigned for use on a permanent basis?
 
  Thank you for all your time, and consideration.


 http://lmgtfy.com/?q=freebsd+change+mac+address

Further internet searches provided useless, incorrect information.
So, just for kicks, I spun up, and installed a copy PC-BSD-9.
The LXDE desktop provided a network applet that allowed to use
the hardware MAC(3), or one of my choosing. I chose my own.
But even that failed. So I attempted to use:

 # ifconfig ue0 ether ##:##:##:##:##:##
 # ifconfig ue0
ether ##:##:##:##:##:##
 # dhclient ue0
blah, blah, blah
 # ping yahoo.com
64 bytes from 98.138.253.109: icmp_seq=0 ttl=53 time=48.867 ms
64 bytes from 98.138.253.109: icmp_seq=1 ttl=53 time=51.118 ms
64 bytes from 98.138.253.109: icmp_seq=2 ttl=53 time=80.145 ms
64 bytes from 98.138.253.109: icmp_seq=3 ttl=53 time=48.964 ms

OK. So it is possible with BSD. Let's try to make it permanent!
adding any of the following attempts failed miserably:
ifconfig_ue0=ether ##:##:##:##:##:## DHCP

ifconfig_ue0=DHCP
ifconfig_ue0_alias0=ether ##:##:##:##:##:##

So apparently it's not possible (for me) to accomplish this
with anything but Linux. Bummer, have used BSD exclusively
since the early 80's. Couldn't imagine having to use anything
else. :(



 --
 Adam Vande More
 ___
 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

Re: MAC cloning available like Linux has?

[Chris H]

Greetings, and thank you for taking the time to respond...

 On Fri, Dec 14, 2012 at 02:46:33PM -0800, Chris H wrote:
  On Fri, Dec 14, 2012 at 12:11 PM, Chris H chris#@1command.com wrote:
 
   Greetings,
I attempted another BSD install on another piece of hardware the
   other day. I'm evaluating a different ISP, and the gateway/router/modem
   they provided, has 1 ether, which I currently use on my server, and 1
   USB(3) port that I had intended to use with the new install. Problem I
   ran into, was that BSD generates random (fake) MAC(3) addresses, when
   utilizing the CDCE(4)/ue0. This worked just fine during the install.
   But the modem held the MAC(3) generated during the install, and I
   now have no idea how to tell BSD to use that MAC(3) when negotiating
   with the modem. I had absolutely no difficulty assigning the MAC(3)
   address when spinning up several live Linux distro(s) -- they provide
   the following:
   su
   password: ***
   ifconfig eth1 down
   ifconfig eth0 hw ether ##:##:##:##:##:##
   dhclient eth0
   blah, blah, blah
  EDIT
  those _should_ have all read eth1 in the session quoted above.
  Sorry.
  
   And I'm connected.
   Couldn't manage that with BSD. What must I do? Is it even possible?
   If so, can it be assigned for use on a permanent basis?
  
   Thank you for all your time, and consideration.
 
 
  http://lmgtfy.com/?q=freebsd+change+mac+address

 Further internet searches provided useless, incorrect information.
 So, just for kicks, I spun up, and installed a copy PC-BSD-9.
 The LXDE desktop provided a network applet that allowed to use
 the hardware MAC(3), or one of my choosing. I chose my own.
 But even that failed. So I attempted to use:

  # ifconfig ue0 ether ##:##:##:##:##:##
  # ifconfig ue0
 ether ##:##:##:##:##:##
  # dhclient ue0
 blah, blah, blah
  # ping yahoo.com
 64 bytes from 98.138.253.109: icmp_seq=0 ttl=53 time=48.867 ms
 64 bytes from 98.138.253.109: icmp_seq=1 ttl=53 time=51.118 ms
 64 bytes from 98.138.253.109: icmp_seq=2 ttl=53 time=80.145 ms
 64 bytes from 98.138.253.109: icmp_seq=3 ttl=53 time=48.964 ms

 OK. So it is possible with BSD. Let's try to make it permanent!
 adding any of the following attempts failed miserably:
 ifconfig_ue0=ether ##:##:##:##:##:## DHCP

 ifconfig_ue0=DHCP
 ifconfig_ue0_alias0=ether ##:##:##:##:##:##

 So apparently it's not possible (for me) to accomplish this
 with anything but Linux. Bummer, have used BSD exclusively
 since the early 80's. Couldn't imagine having to use anything
 else. :(



 ifconfig_ue0=ether ##:##:##:##:##:##; DHCP

BRILLIANT!
If _only_ I had not overlooked that semicolon. :/

Thank you Mateusz Guzik! Greatly appreciated.


 --
 Mateusz Guzik mjguzik 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

Re: MAC cloning available like Linux has?

[Chris H]

 On Fri, Dec 14, 2012 at 2:46 PM, Chris H chris#@1command.com wrote:

 ifconfig_ue0=DHCP
 ifconfig_ue0_alias0=ether ##:##:##:##:##:##

 So apparently it's not possible (for me) to accomplish this
 with anything but Linux. Bummer, have used BSD exclusively
 since the early 80's. Couldn't imagine having to use anything
 else. :(


 You're just not trying hard enough, or thinking logically enough.  ;)

Or _too_ hard -- making it harder than it really is. ;)

 ifconfig then dhclient works.  Yet you configure rc.conf to do dhclient
 then ifconfig.  :)

D'OH!


 Reverse your rc.conf entries to match what you did at the command prompt:

 ifconfig_ue0=ether blah blah blah
 ifconfig_ue0_alias0=DHCP

Thanks/1 That will _clearly_ work.

Thanks for Freddie, for taking the time to respond.


 --
 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

Re: MAC cloning available like Linux has?

[Chris H]

 On Fri, Dec 14, 2012 at 02:46:33PM -0800, Chris H wrote:
 OK. So it is possible with BSD. Let's try to make it permanent!
 adding any of the following attempts failed miserably:
 ifconfig_ue0=ether ##:##:##:##:##:## DHCP

 ifconfig_ue0=DHCP
 ifconfig_ue0_alias0=ether ##:##:##:##:##:##


 Try this:

 ifconfig_ue0=DHCP
 create_args_ue0=ether ##:##:##:##:##:##

Excellent! I had never heard/seen the _args_ option for NIC's before.
Thank you!

--Chris


 Glen



___
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: MAC cloning available like Linux has?

[Chris H]

 On Fri, Dec 14, 2012 at 02:46:33PM -0800, Chris H wrote:
 OK. So it is possible with BSD. Let's try to make it permanent!
 adding any of the following attempts failed miserably:
 ifconfig_ue0=ether ##:##:##:##:##:## DHCP

 ifconfig_ue0=DHCP
 ifconfig_ue0_alias0=ether ##:##:##:##:##:##

Well, dfeeling armed, and dangerous with the new knowledge
gained from Mateusz Guzik, Freddie Cash, and Glen Barber,
I downloaded CD1 of RELENG_9, and installed it.
I attempted to use the suggestions previously provided.
However, they were either rejected, or quietly ignored. :(

with: ifconfig_ue0=ether ##:##:##:##:##:##; DHCP
the ether isn't honored (ignored)

ifconfig_ue0=ether blah blah blah
ifconfig_ue0_alias0=DHCP
throws an error (but spins by too fast to catch)
/var/log/messages would probably reveal it.

ifconfig_ue0=DHCP
create_args_ue0=ether ##:##:##:##:##:##
create_args is simply ignored.

I don't get it. I've tried every imaginable incarnation I
could possibly conceive. Is it even possible? I had really
hoped to turn this into a gateway, and while Linux will
clone the MAC(3). I don't trust it (security wise).
Is Linux' DHCP more robust than BSD'?! Hard to imagine,
but I'm completely at a loss.

--Chris

___
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