Re: Desired behaviour of "ifconfig -alias"
On Tuesday 13 February 2007 04:57, Oliver Fromme wrote: > Kevin Way wrote: > > Oliver Fromme wrote: > > > But you called it "confusing". That's just your personal > > > perception. It doesn't mean it is confusing to everybody. > > > > > If asked what -alias does, would you really reply "it removes the > > primary IP, > > while leaving the alias?" Be honest here. > > No, I wouldn't answer that, because there is no such thing > as a primary IP. All IPs on an interface are equal. The > term alias exists only for historical reasons, and it's > clearly becoming obsolete. my dear friend I really do not know why you insist on writing this again and again. Firstable it is wrong what you say. IP Aliasing is a correct and perfect term, used since it is possible to set more then one IP and people use it all over the world, in simple networks and specially in hosting environments. So it probably never will become obsolete because firstable it is THE word in use everywhere, it is grammatically correct and it is easy to understand. It does not exist for historical reasons. It is part of IP history and an important one, exist because it is in use and so it will stay with us - in all OSs ... and almost all languages it is understood as it is - perfectly by definition. The only correct thing you say here is that all IPs are equal - and - nobody EVER said something different. Aliasing does not say anything about priority of the Ip it is simply related to the time the interface was set with the IP so the first IP is the one which was set first and the first alias is the one which was set after. So by common sense alias describes an additional IP address which was add to an already existent address. Otherwise it would not be an alias. This understanding, which is completely correct, makes it wrong that "ifconfig nic -alias" removes an IP address which is unique on this interface. At least when done without warning. And also makes it wrong to remove the IP which was set first on this interface since it is not an alias by common understanding even if it is equal in technical functions. Then, at the end it is perfectly ok when people say primary address because it might be for them THE address of THEIR machine. This is manner of speaking and they are probably fully aware of that the other IPs are equal. And so this must be bethought, you can not run against common sense even if there might be something not exactly expressed. By all respect, you are running against the wall here. -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
JoaoBR <[EMAIL PROTECTED]> wrote: > Oliver Fromme wrote: > > No, not at all. As soon as you use the terms "primary IP > > address" and "secondary IP addresses", you imply that they > > are not equal. But they are equal. It's just a list of > > IP addresses assigned to an interface which happens to have > > a certain order. > > > > nobody claims that there is an master-slave order or something, alias is the > secondary in order of time, but not in value, I do not even understand why > you talking so much about this, the point is more than clear No, it doesn't seem to be clear to you. As soon as you use the terms "primary" and "secondary", you are implying a certain order in the meaning of the IP addresses. But as far as the ifconfig(8) tool is concerned, there is no order, no matter ow you would interpret it. In theory, ifconfig could print the IP addresses for an interface in random order, and each time in a different order. Which of them would you call "primary" then? Which of them would be "aliases"? > > > > If no IP address is specified, then it's not completely > > > > nonsensical to remove the first address. In fact I've > > > > used that short-cut to quickly remove the only address > > > > from an interface. I've used "ifconfig xyz0 delete" > > > > quite a lot. > > yes it is! it does not matter which word, without an IP address it should > NOT > remove anything I understand that that's your preference. But it's not mine. People clearly have different opinions on that subject. That doesn't mean that one opinion is right and the other is wrong. It's just a matter of perception. Currently it is undocumented what the ifconfig command does when no IP address is specified. While you could assume that it prints a syntax error message, it is not guaranteed that it does. Basically there are two possibilities: Change the man page so it documents the behaviour correctly. Or change the program so it prints an error message, _and_ change the man page so it documents that fact. Personally, as I've already mentioned, I would prefer to solve the problem by printing the error message for the "-alias" parameter only, but keep the current behaviour for the "delete" and "remove" parameters. Another possibility, of course, is to make the behaviour configurable, e.g. dependant on a variable such as IFCONFIG_TRADITIONAL or IFCONFIG_FORSISSIES. > > > the man page tells us that -alias removes *the* specified address and > > > not the first, also the man page does not say that there is any further > > > action when *no* IP address specified > > > > That's true. Usually if something is not documented, the > > behaviour is undefined. > > undefined is absolutely not similar to remove something .. "Undefined" can mean anything. There are quite a lot of examples of undefined behaviour. > all commands which remove something "usally" say something when trying to > use > without value, rm, rmdir, rmuser ... I really do not remember any other > then -alias which does so >From the top of my head, lprm(1) does so. However, the difference is that it's documented in its manual page. > > In fact, it might also make sense to enhance the syntax > > to allow the specification of a number, for example > > "ifconfig xyz0 delete #2" would remove the second address > > my god what a horrible idea is that! You fail to explain why. I think it would be very useful and less error prone, because typing a single digit is easier than typing an IP address. > do you remember "#" in UNIX You did not quote my next sentence (intentionally?) where I wrote that the syntax was just an example. My point was the functionality, not the exact syntax in that example. I also wouldn't object "ifconfig xyz0 delete all" which would quickly delete all addresses from an interface. I could have used that more than once, really. Instead, currently I have to use "ifconfig xyz0 delete" several times until I get EADDRNOTAVAIL (thankfully there's a shell history, so I just need to press Cursor-up and Enter repeatedly). > the command "ifconfig nic -alias IP" is OK, perfect, even delete is, the > problem and the only problem is that both remove without specifying a value > a > value and that *IS* wrong behaviour, Neither you nor me decide what is "wrong". Actually I think there is no right or wrong here. The issue is that every behaviour clearly has advantages and disadvantages. Whether one is "more wrong" or "more right" (i.e. has more disadvantages than advantages or vice versa) can be debated, as we see here. There are quite a lot of points that need to be taken into consideration. 1. Standards compliance, if applicable. 2. Consistency with other operating systems, if desirable. 3. Consistency with historic behaviour. 4. POLA compliance. 5. Possibility of breakage when changes are made. 6. Feature regression. 7. Convenience of usage. 8. ... and probably much mo
Re: Desired behaviour of "ifconfig -alias"
J. T. Farmer wrote: > Oliver Fromme wrote: > > But when removing something without specifying which one, > > it makes some sense to simply remove the first existing > > address on that interface. It would even be OK with me > > to remove the last one, or an arbitrary one -- I use that > > shortcut mostely when I need to remove the only address > > from an interface (or all existing addresses), so it > > doesn't matter. > > Doing apparently random and arbitrary things is bad, regardless. I agree that it's bad if it's not well documented, which is the case here, unfortunately. > re-cast the argument, suppose you found out that your employer had > a command in the company accounting system called > "VacationConfig -transfer" that would transfer random days from your > vacation pot to some arbitrary receiver. .. Well, if it was documented ... But it would probably violate my work contract, so he'd better not use the command. ;-) > It is very clear that ifconfig does not behave in the manner that the man > pages claim. It's true that the manpage is very unclear and needs to be improved. It's also true that the command line parser of ifconfig is a rather complex beast that has grown in nasty ways over the years. Maybe now would be the right time to completely redesign the ifconfig tool. Only in -current, of course, with very big HEADS-UP warning in the lists and in UPDATING. But I fear that there are no devloper resources to do that right, so any change will end up as just another patch work that won't really clean things up, but instead make it worse. :-/ > that way in -current. Then MFC it back to -stable... I don't think that any significant changes in the behaviour of such an important tool will be MFC'ed to a stable branch. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
JoaoBR wrote: The only correct thing you say here is that all IPs are equal - and - nobody EVER said something different. Aliasing does not say anything about priority of the Ip it is simply related to the time the interface was set with the IP so the first IP is the one which was set first and the first alias is the one which was set after. The thing is, source selection policy and IP address scope blow the assumptions in this discussion out of the water, as does the concept of unnumbered IP interfaces. Scoping and selection policy is necessary to support link-local IPv4 (Zeroconf) and IPv6 as we move swiftly into a world where these things are a fact of life, and make deployment of useful IP networks for non computer users a reality. Interface preference is desirable in a stack supporting multipathing. Unnumbered IP, for example, is not dealt with at all well by the BSD stack. There are situations in which it is perfectly valid; a newly booting machine; a router at the end of a PPP link. We deal with something like 30% of the problem space for unnumbered IP. We need to be able to tell the IP stack 'be attached to this interface without a configured IP'. ifconfig syntax currently doesn't capture this requirement; the keywords 'add/delete' are closer to this intent. In the meantime, attachment of an address family to an ifnet in the kernel depends upon having at least one address configured, therefore 'alias/-alias' is the best fit to the current reality of the code. I look forward to seeing patches as a result of this discussion if anybody actually wishes to change anything. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What is a good choice of sata-ii raid controller for freebsd?
Hi. Interesting - Someone else mentioned the same thing. The amr(4) manpage doesn't seem to be updated to mention the latest cards though. I did notice the driver hasn't been really updated in a while either. Wouldn't this cause a problem with identifying the newer cards? The authoritative source is the source itself: grep amr_device_ids /usr/src/sys/dev/amr/amr_pci.c -- ./lxnt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: What is a good choice of sata-ii raid controller for freebsd?
> > Interesting - Someone else mentioned the same thing. The amr(4) > > manpage doesn't seem to be updated to mention the latest cards > > though. I did notice the driver hasn't been really updated in a > > while either. Wouldn't this cause a problem with identifying the > > newer cards? > > > > The authoritative source is the source itself: >grep amr_device_ids /usr/src/sys/dev/amr/amr_pci.c True - But without having a card to check the ids, it doesn't help all that much. After a bunch of downloading WinXP drivers to look up vendor ids, it seems that the FreeBSD driver does not support any of the PCI Express boards (or Server boards) at this point in time. Jaime Bozza Qlinks Media Group ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Tuesday 13 February 2007 02:38 am, Oliver Fromme wrote: > JoaoBR <[EMAIL PROTECTED]> wrote: > > Oliver Fromme wrote: > > > No, not at all. As soon as you use the terms "primary IP > > > address" and "secondary IP addresses", you imply that they > > > are not equal. But they are equal. It's just a list of > > > IP addresses assigned to an interface which happens to have > > > a certain order. > > > > nobody claims that there is an master-slave order or something, > > alias is the secondary in order of time, but not in value, I do not > > even understand why you talking so much about this, the point is > > more than clear > > No, it doesn't seem to be clear to you. > > As soon as you use the terms "primary" and "secondary", > you are implying a certain order in the meaning of the > IP addresses. But as far as the ifconfig(8) tool is > concerned, there is no order, no matter ow you would > interpret it. In theory, ifconfig could print the IP > addresses for an interface in random order, and each > time in a different order. Which of them would you > call "primary" then? Which of them would be "aliases"? For a set of IPs in the same subnet on the same interface, wouldn't the primary IP be the one with the proper netmask, and all IPs with netmasks of /32 be secondary? In that situation, wouldn't deleting the primary IP cause connection issues for the rest of the IPs? For a set of IPs in separate subnets, each with their own non-/32 netmasks, there wouldn't really be a distinction between primary / secondary. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
> For a set of IPs in the same subnet on the same interface, wouldn't the > primary IP be the one with the proper netmask, and all IPs with netmasks > of /32 be secondary? In that situation, wouldn't deleting the primary IP > cause connection issues for the rest of the IPs? Indeed. I too am not convinced by the 'there is no such thing as a primary IP address' thing either - because it's trivial to observe that if you add several addresses to an interface and make outgoing connections then one of those (the one with the correct netmask) is always the one used as the source address. Which looks suspiciously like a primary IP address to me - or at least one which is being treated slightly differently to all the others on that interface anyway. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Monday 12 February 2007 11:57 pm, Oliver Fromme wrote: > Kevin Way wrote: > > Oliver Fromme wrote: > > > But you called it "confusing". That's just your personal > > > perception. It doesn't mean it is confusing to everybody. > > > > If asked what -alias does, would you really reply "it removes the > > primary IP, > > while leaving the alias?" Be honest here. > > No, I wouldn't answer that, because there is no such thing > as a primary IP. All IPs on an interface are equal. The > term alias exists only for historical reasons, and it's > clearly becoming obsolete. > > If asked what "-alias" does, I would reply that it is an > alias for "delete" or "remove", which removes an IP address > from an interface. According to the docs, the IP address > to be removed must be specified. The docs don't mention > what happens if none is specified, so the behaviour is > undefined and should not be relied on. It just happens [insert tongue into cheek] Hmmm, so if the behaviour is undefined, and should not be relied upon, why is everyone arguing to keep it as they rely upon it? :) If no one should be relying upon this undefined behaviour, then why not fix it and make it reliable? -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Tuesday 13 February 2007 12:44 am, JoaoBR wrote:
> On Monday 12 February 2007 22:37, Joerg Pernfuss wrote:
> > On Mon, 12 Feb 2007 19:18:54 -0300
> >
> > JoaoBR <[EMAIL PROTECTED]> wrote:
> > > I believe the problem here is that
> > >
> > > ifconfig_nic="inet IP"
> > > ifconfig_nic="ether MAC"
> > >
> > > does not work on one line and does not work on two either, the
> > > latter overrides and or you get an IP address with original MAC or
> > > you get a new MAC without IP.
> >
> > Yes, you have to put 'ifconfig nic ether MAC' in /etc/start_if.nic
> > for this to work afair. Same approach you need to set WEP etc on a
> > wireless nic if you have ifconfig_nic="DHCP" in your rc.conf.
>
> if I am remembering well dhcp things you can put into dhclient.conf as
>
> interface "nic" {
> media "ssid SSID nwkey KEY";
> }
>
> or so to be set before sending the dhcp request.
/etc/wpa_supplicant.conf works much nicer for this. Put all the wireless
settings in there (including unencrypted, WEP, or WPA) for as many
different networks as you want. Add WPA to the ifconfig line
in /etc/rc.conf. Then wpa_supplicant handles scanning for networks,
associating to the access point, and bringing the interface "up". Only
after the interface is "up" will dhclient be run.
--
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Tue, Feb 13, 2007 at 05:19:59PM +, Pete French wrote: > > For a set of IPs in the same subnet on the same interface, wouldn't the > > primary IP be the one with the proper netmask, and all IPs with netmasks > > of /32 be secondary? In that situation, wouldn't deleting the primary IP > > cause connection issues for the rest of the IPs? > > Indeed. I too am not convinced by the 'there is no such thing as a > primary IP address' thing either - because it's trivial to observe > that if you add several addresses to an interface and make outgoing > connections then one of those (the one with the correct netmask) is > always the one used as the source address. Which looks suspiciously like > a primary IP address to me - or at least one which is being treated > slightly differently to all the others on that interface anyway. I agree. I consider the "primary IP" the first (non-aliased) IP bound to the interface. This is the same IP used by default if no particular IP address is explicitly populated sockaddr_in.sin_addr.s_addr during bind(2). I think most system administrators consider a "primary IP" the same thing I do. The underlying API probably does not differentiate any of them (although the routing table seems to differentiate aliases from the "primary IP"; look at netstat -rn), but underlying socket calls probably pick the first entry in the "address index table" per interface when one is not defined, probably based on the routing table too. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on USB flash memory
Jeremy Chadwick wrote: > I think this has been discussed before. The problem is that FreeBSD's > bootloader doesn't support booting off of such devices, thus you > need to use GRUB or another bootloader. But the guy from tutorial is doing that, and I made such a stick too. And it boots on ThinkPad X40 perfectly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic: 6.2-STABLE/RELEASE, sysctl (on boot) -- ath related
Hi, While upgrading a fileserver / home wireless access point to 6.2-RELEASE, it wouldn't come back after the regular build/installworld/mergemaster procedures. I attached a keyboard and monitor to the server and noticed it was panicking on boot, current process being sysctl: Feb 13 18:27:51 hyperblast kernel: Fatal trap 12: page fault while in kernel mode Feb 13 18:27:51 hyperblast kernel: fault virtual address= 0x0 Feb 13 18:27:51 hyperblast kernel: fault code = supervisor read, page not present Feb 13 18:27:51 hyperblast kernel: instruction pointer = 0x20:0xc06fb2a6 Feb 13 18:27:51 hyperblast kernel: stack pointer= 0x28:0xd9734ad8 Feb 13 18:27:51 hyperblast kernel: frame pointer= 0x28:0xc3383000 Feb 13 18:27:51 hyperblast kernel: code segment = base 0x0, limit 0xf, type 0x1b Feb 13 18:27:51 hyperblast kernel: = DPL 0, pres 1, def32 1, gran 1 Feb 13 18:27:51 hyperblast kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Feb 13 18:27:51 hyperblast kernel: current process = 186 (sysctl) Feb 13 18:27:51 hyperblast kernel: trap number = 12 Feb 13 18:27:51 hyperblast kernel: panic: page fault Feb 13 18:27:51 hyperblast kernel: Uptime: 3s Feb 13 18:27:51 hyperblast kernel: Cannot dump. No dump device defined. Feb 13 18:27:51 hyperblast kernel: Automatic reboot in 15 seconds - press a key on the console to abort Feb 13 18:27:51 hyperblast kernel: --> Press a key on the console to reboot, Feb 13 18:27:51 hyperblast kernel: --> or switch off the system now. Feb 13 18:27:51 hyperblast kernel: Rebooting... The last line seen before the panic is sysctl adjusting values (according to sysctl.conf): # tail /etc/sysctl.conf dev.ath.0.tpscale=1 dev.ath.0.diversity=0 Now, there are two interesting things to note: a) If I uncomment these lines with the system running and reload (/etc/rc.d/sysctl reload), there's no panic. b) It used to work just fine on 6.0-RELEASE-p5. It is not a big deal, but just something that perhaps should be fixed. For the records, I tried -RELEASE and -STABLE. Currently running -STABLE (as of 2007-02-12 @ about 2AM GMT) Best regards, Hugo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
Freddie Cash wrote: > For a set of IPs in the same subnet on the same interface, wouldn't the > primary IP be the one with the proper netmask, and all IPs with netmasks > of /32 be secondary? That's historic. :-) Old versions of FreeBSD indeed required the netmask of the "aliases" to be /32 in that case. But it's no longer the case. # ifconfig re0 re0: flags=8843 mtu 1500 options=1b inet 88.198.44.136 netmask 0xffe0 broadcast 88.198.44.159 inet 88.198.173.154 netmask 0xfff8 broadcast 88.198.173.159 inet 88.198.173.155 netmask 0xfff8 broadcast 88.198.173.159 inet 88.198.173.156 netmask 0xfff8 broadcast 88.198.173.159 inet 88.198.173.157 netmask 0xfff8 broadcast 88.198.173.159 inet 88.198.173.158 netmask 0xfff8 broadcast 88.198.173.159 > In that situation, wouldn't deleting the primary IP > cause connection issues for the rest of the IPs? No. I can delete _any_ of the above IP addresses, and the others would still work perfectly fine. I already did things like that (on a different machine). As for outgoing connections: It is true that the kernel picks a random matching IP address to be the source IP, which happens to be the first one, but that's just as coincidence as "-alias" picking the first one if none is given. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
Freddie Cash wrote: > Oliver Fromme wrote: > > If asked what "-alias" does, I would reply that it is an > > alias for "delete" or "remove", which removes an IP address > > from an interface. According to the docs, the IP address > > to be removed must be specified. The docs don't mention > > what happens if none is specified, so the behaviour is > > undefined and should not be relied on. It just happens > > [insert tongue into cheek] > Hmmm, so if the behaviour is undefined, and should not be relied upon, > why is everyone arguing to keep it as they rely upon it? :) Good question. Personally I use that "feature" only at the shell prompt (interactively) because it saves typing and potentially reduces typing errors. And I see imemdiately if it fails or produces unexpected results. In scripts I always use the documented syntax, so there's no danger. > If no one should be relying upon this undefined behaviour, then why > not fix it and make it reliable? Exactly. That's what I'm suggesting. Fix the manual page, so the behaviour isn't undefined anymore, thus make it reliable. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." -- Oddbjorn Steffensen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Tuesday 13 February 2007 10:37 am, Oliver Fromme wrote: > Freddie Cash wrote: > > For a set of IPs in the same subnet on the same interface, wouldn't > > the primary IP be the one with the proper netmask, and all IPs with > > netmasks of /32 be secondary? > > That's historic. :-) Old versions of FreeBSD indeed > required the netmask of the "aliases" to be /32 in that > case. But it's no longer the case. Hmmm, if this is the case, then the man page for ifconfig(8) is out-of-date wrt this as well: alias Establish an additional network address for this interface. This is sometimes useful when changing network numbers, and one wishes to accept packets addressed to the old interface. If the address is on the same subnet as the first network address for this interface, a non-conflicting netmask must be given. Usually 0x is most appropriate. > # ifconfig re0 > re0: flags=8843 mtu 1500 > options=1b > inet 88.198.44.136 netmask 0xffe0 broadcast 88.198.44.159 > inet 88.198.173.154 netmask 0xfff8 broadcast 88.198.173.159 > inet 88.198.173.155 netmask 0xfff8 broadcast 88.198.173.159 > inet 88.198.173.156 netmask 0xfff8 broadcast 88.198.173.159 > inet 88.198.173.157 netmask 0xfff8 broadcast 88.198.173.159 > inet 88.198.173.158 netmask 0xfff8 broadcast 88.198.173.159 > > > In that situation, wouldn't deleting the primary IP > > cause connection issues for the rest of the IPs? > > No. I can delete _any_ of the above IP addresses, and the > others would still work perfectly fine. I already did > things like that (on a different machine). Yes, but each of the IPs is on their own subnet. I'm talking about a situation where one IP on the interface has a /24 netmask, and all the other IPs on the interface have /32 netmasks. Would removing the IP with a /24 netmask cause connection issues for the other IPs on that interface? I don't have access to a test box at the moment (that's at home) to check. > As for outgoing connections: It is true that the kernel > picks a random matching IP address to be the source IP, > which happens to be the first one, but that's just as > coincidence as "-alias" picking the first one if none > is given. ;-) Is it a coincidence, though? If you add the following IPs to an interface: x.x.x.2/24 x.x.x.3/32 x.x.x.4/32 x.x.x.5/32 Then remove x.x.x.2, and re-add it as x.x.x.2/24 so it appears at the bottom of the list of IPs, what IP is used for outgoing connections? My gut tells me it'll be x.x.x.2, but I'll have to check that when I get home. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
> > In that situation, wouldn't deleting the primary IP > > cause connection issues for the rest of the IPs? > > No. I can delete _any_ of the above IP addresses, and the > others would still work perfectly fine. I already did > things like that (on a different machine). > > As for outgoing connections: It is true that the kernel > picks a random matching IP address to be the source IP, > which happens to be the first one, but that's just as > coincidence as "-alias" picking the first one if none > is given. ;-) If it is indeed true that the kernel picks a *random* IP address for the source IP, I'd have to say that's not at all good enough. I'm all for being able to use the same netmask for several addresses in the same subnet (I have asked for this before) - but the source IP used by traffic generated from the host itself *must* be predictable. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
* Oliver Fromme <[EMAIL PROTECTED]> [20070212 19:11]: > But you called it "confusing". That's just your personal > perception. It doesn't mean it is confusing to everybody. > In fact it might be useful to others. It _is_ useful to > me, for example, and I would object for that syntax to go > away. Also note that it doesn't hurt anybody. Until it appears on a system startup script that ends up dropping your connection (so, go fix rc.d/jail ...). qvb -- pica ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
Hi! On Tue, Feb 13, 2007 at 07:37:17PM +0100, Oliver Fromme wrote: > Freddie Cash wrote: > > For a set of IPs in the same subnet on the same interface, wouldn't the > > primary IP be the one with the proper netmask, and all IPs with netmasks > > of /32 be secondary? > > That's historic. :-) Old versions of FreeBSD indeed > required the netmask of the "aliases" to be /32 in that > case. But it's no longer the case. WTF? Er, sorry, what did I miss? This is complete news to me and I'm really surprised. I had that same thought as Freddie had when I read this thread, but did not find the time to answer until today. Was there a HEADS UP or something? > > In that situation, wouldn't deleting the primary IP > > cause connection issues for the rest of the IPs? > > No. I can delete _any_ of the above IP addresses, and the > others would still work perfectly fine. I already did > things like that (on a different machine). _If_ they all share the same netmask when they are part of the same prefix. As much as I appreciate the change, this is a big POLA violation. I considered the "netmask 0x" cast in concrete until now. Thanks for clarifying. Patrick -- punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
[EMAIL PROTECTED] wrote: > > > > In that situation, wouldn't deleting the primary IP > > > cause connection issues for the rest of the IPs? > > > > No. I can delete _any_ of the above IP addresses, and the > > others would still work perfectly fine. I already did > > things like that (on a different machine). > > > > As for outgoing connections: It is true that the kernel > > picks a random matching IP address to be the source IP, > > which happens to be the first one, but that's just as > > coincidence as "-alias" picking the first one if none > > is given. ;-) > > If it is indeed true that the kernel picks a *random* IP address for > the source IP, I'd have to say that's not at all good enough. Well, "random" was probably misleading, I'm sorry. It should better be called "arbitrary", I think. > I'm all for being able to use the same netmask for several addresses > in the same subnet (I have asked for this before) - but the source IP > used by traffic generated from the host itself *must* be predictable. It _is_ predictable, it is the first address currently configured on the interface. But doing so is (was) an arbitrary decision. Of course, if you remove the first address, it will simply use the next one (which will then become the first one). On the other hand, if you need to guarantee that a certain address is used as source IP for outgoing connections, then you should explicitly bind the socket to that address. Many programs have an option to do that, or -- if they don't -- it's usually not too difficult to insert a bind(2) call into the source yourself. Another way to do it is to run the program inside a jail; you don't even have to set up a chroot if you don't want to: # jail / `hostname` $IP /path/to/program I would advise against relying on the current behaviour that the kernel always picks the first address as the source address for a subnet for unbound sockets. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
Freddie Cash wrote: > Oliver Fromme wrote: > > Freddie Cash wrote: > > > For a set of IPs in the same subnet on the same interface, wouldn't > > > the primary IP be the one with the proper netmask, and all IPs with > > > netmasks of /32 be secondary? > > > > That's historic. :-) Old versions of FreeBSD indeed > > required the netmask of the "aliases" to be /32 in that > > case. But it's no longer the case. > > Hmmm, if this is the case, then the man page for ifconfig(8) is > out-of-date wrt this as well: > > alias Establish an additional network address for this interface. This >is sometimes useful when changing network numbers, and one wishes >to accept packets addressed to the old interface. If the address >is on the same subnet as the first network address for this >interface, a non-conflicting netmask must be given. Usually >0x is most appropriate. Well, yes, the ifconfig(8) manual page is lacking in several aspects, it seems. > > # ifconfig re0 > > re0: flags=8843 mtu 1500 > > options=1b > > inet 88.198.44.136 netmask 0xffe0 broadcast 88.198.44.159 > > inet 88.198.173.154 netmask 0xfff8 broadcast 88.198.173.159 > > inet 88.198.173.155 netmask 0xfff8 broadcast 88.198.173.159 > > inet 88.198.173.156 netmask 0xfff8 broadcast 88.198.173.159 > > inet 88.198.173.157 netmask 0xfff8 broadcast 88.198.173.159 > > inet 88.198.173.158 netmask 0xfff8 broadcast 88.198.173.159 > > > > > In that situation, wouldn't deleting the primary IP > > > cause connection issues for the rest of the IPs? > > > > No. I can delete _any_ of the above IP addresses, and the > > others would still work perfectly fine. I already did > > things like that (on a different machine). > > Yes, but each of the IPs is on their own subnet. No, please look closer. The addresses above are all in the same subnet (except for the first one). It's a /29 subnet in this case, but it works exactly the same with /24 or any other subnet masks. > I'm talking about a > situation where one IP on the interface has a /24 netmask, and all the > other IPs on the interface have /32 netmasks. Would removing the IP with > a /24 netmask cause connection issues for the other IPs on that > interface? I'm not sure. I think they should just continue to work, but I would have to try that. But why would you want to use /32 netmasks? That was just a hack for the historic limitation that you couldn't use real netmasks for IPs within the same subnet. There's no reason to use that hack anymore. > If you add the following IPs to an interface: >x.x.x.2/24 >x.x.x.3/32 >x.x.x.4/32 >x.x.x.5/32 > Then remove x.x.x.2, and re-add it as x.x.x.2/24 so it appears at the > bottom of the list of IPs, what IP is used for outgoing connections? As I said, I would have to try that because I haven't used the /32 netmask hack for quite some time. I think it would indeed use the first address, i.e. x.x.x.2. > My gut tells me it'll be x.x.x.2, but I'll have to check that when I get > home. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Tue, Feb 13, 2007 at 09:36:25PM +0100, Oliver Fromme wrote: > > > # ifconfig re0 > > > re0: flags=8843 mtu 1500 > > > options=1b > > > inet 88.198.44.136 netmask 0xffe0 broadcast 88.198.44.159 > > > inet 88.198.173.154 netmask 0xfff8 broadcast 88.198.173.159 > > > inet 88.198.173.155 netmask 0xfff8 broadcast 88.198.173.159 > > > inet 88.198.173.156 netmask 0xfff8 broadcast 88.198.173.159 > > > inet 88.198.173.157 netmask 0xfff8 broadcast 88.198.173.159 > > > inet 88.198.173.158 netmask 0xfff8 broadcast 88.198.173.159 > > > > > > > In that situation, wouldn't deleting the primary IP > > > > cause connection issues for the rest of the IPs? > > > > > > No. I can delete _any_ of the above IP addresses, and the > > > others would still work perfectly fine. I already did > > > things like that (on a different machine). > > > > Yes, but each of the IPs is on their own subnet. > > No, please look closer. The addresses above are all in the > same subnet (except for the first one). It's a /29 subnet > in this case, but it works exactly the same with /24 or any > other subnet masks. Your configuration looks incorrect. How or why it's working is proof that the implementation (read: source code) differs from what some of the docs state. My guess is that it's working because you already have AFAIK, it should be (note alias entries 2,3,4): ifconfig_re0="inet 88.198.44.136 netmask 255.255.255.240" ifconfig_re0_alias0="inet 88.198.173.154 netmask 255.255.255.248" ifconfig_re0_alias1="inet 88.198.173.155 netmask 255.255.255.255" ifconfig_re0_alias2="inet 88.198.173.156 netmask 255.255.255.255" ifconfig_re0_alias3="inet 88.198.173.157 netmask 255.255.255.255" ifconfig_re0_alias4="inet 88.198.173.158 netmask 255.255.255.255" My guess is that it's working because your routing table already has an entry for 88.198.173.154/29 which was created by the first entry. The remaining aliases on that network (88.198.173.154/29) utilise that, but should really have netmasks with all 1s. ifconfig(8) states you should use 255.255.255.255/0x (all 1s) for IP aliases. The FreeBSD Handbook documents everything I've said quite clearly: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-virtual-hosts.html > As I said, I would have to try that because I haven't used > the /32 netmask hack for quite some time. I think it would > indeed use the first address, i.e. x.x.x.2. As far as I know it's not a hack. If it is/was a hack, can you explain the functional difference between IP aliases with a 0x netmask vs. mixed-set-bits, and point to some past references stating the difference? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What is a good choice of sata-ii raid controller for freebsd?
One thing I would like to see is a list of favoured non-raid multiport cards that are not dumb. We have a server running a rocket RAID controller (largely to get 8 ports of SATA). It doesn't do hot swap, it doesn't do SMART and I'm beginning to believe it might occasionally corrupt sectors (very occasionally). What I'd like to see is 4, 8 and 16 port JBOD controllers that work and are reasonably priced. I don't care about hardware RAID support (it is trivial to create systems that can boot from multiple disks with geom --- it's in the handbook). I don't care if they appear as SCSI or ATA disks I just want: 1) Hot swap 2) many ports 3) smartctl working ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in 6.2-PRERELEASE with bge on amd64
On Saturday 10 February 2007 12:33, Bjoern A. Zeeb wrote: > On Sun, 7 Jan 2007, Sven Willenberger wrote: > > > lock order reversal: (sleepable after non-sleepable) > > 1st 0x8836b010 bge0 (network driver) @ /usr/src/sys/dev/bge/if_bge.c:2675 > > 2nd 0x805f26b0 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 > > added with LOD ID 199 to The LOR page: > http://sources.zabbadoz.net/freebsd/lor.html#199 > > I am unsure if this was patched already - if so please let me know. These aren't real LORs, they are a side effect of a panic. Adding these is just going to add clutter I think. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on USB flash memory
Karel Miklav wrote: Jeremy Chadwick wrote: > I think this has been discussed before. The problem is that FreeBSD's > bootloader doesn't support booting off of such devices, thus you > need to use GRUB or another bootloader. But the guy from tutorial is doing that, and I made such a stick too. And it boots on ThinkPad X40 perfectly. It depends on the BIOS, it works on some boards but most new motherboards I've tried gives a BTX halted panic. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
