From: Steven Scholz <hidden> Date: 2003-08-08 15:04:48
Hi there,
Microsoft uses "Automatic Private IP Addressing" to grab an IP address
if a DHCP request fails.
In the section "Resolving IP Conflicts" in
http://www.winnetmag.com/Articles/Index.cfm?ArticleID=7464
it says
How does the client know the IP address it's using isn't in use by
another machine? It uses a gratuitous Address Resolution Protocol
(ARP) to resolve potential conflicts. Let’s say the first client that
boots up wants to assign itself an IP address of 169.254.10.20. It
sends out a gratuitous ARP, but no one answers, so it keeps the
address ... Next, a third client boots up and picks 169.254.10.20, the
same address the first client chose. The first client tells the third
client that it's already using that IP address, so the third client
tries a different IP address and keeps it if there's no conflict.
I can see this behaviour if I connect an embedded DOS TCP/IP device to
a Windows XP computer (using a cross-linked twisted pair) and force
the IP of the DOS device to be the same as the one that the Windows XP
computer is going to claim. Fair enough.
But when I connect my MPC8xx board with Linux it seems that Linux is
not responding to the ARP requests done by the Windows machine.
Result: Both machine end up with the same IP address.
Did I miss something?
I did not find an kernel option saying something about ARP...
Any ideas?
Could someone maybe try this as well? Please?
Thanks a million,
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2003-08-08 18:24:30
Steven Scholz wrote:
But when I connect my MPC8xx board with Linux it seems that Linux is
not responding to the ARP requests done by the Windows machine.
Result: Both machine end up with the same IP address.
Fortunately, Linux isn't Windows......you are going to find lots of
Windows "standard" protocols that aren't documented nor supported by
anyone else.
Did I miss something?
Well, Microsoft did.....there is RFC2131 that describes how you are
supposed to use an ARP to respond to a duplicate IPv4 used on the
network. It is commonly used to ensure you don't have systems
manually configured or not honoring leases when DHCP is handing out
dynamic IP addresses. Everyone else seems to implement this properly.
I did not find an kernel option saying something about ARP...
That's because it implements the standard protocols by default.
Any ideas?
Run DHCP or properly manually configure your Linux system. I don't
know how old your Linux kernel is for the 8xx, but this support for
RFC2131 has been in Linux for a very long time.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Steven Scholz <hidden> Date: 2003-08-12 12:34:12
Dan Malek wrote:
> Steven Scholz wrote:
>
>> But when I connect my MPC8xx board with Linux it seems that Linux is
>> not responding to the ARP requests done by the Windows machine.
>> Result: Both machine end up with the same IP address.
>
>
> Fortunately, Linux isn't Windows......you are going to find lots of
> Windows "standard" protocols that aren't documented nor supported by
> anyone else.
>
>> Did I miss something?
>
>
> Well, Microsoft did.....there is RFC2131 that describes how you are
> supposed to use an ARP to respond to a duplicate IPv4 used on the
> network. It is commonly used to ensure you don't have systems
> manually configured or not honoring leases when DHCP is handing out
> dynamic IP addresses. Everyone else seems to implement this properly.
Finaly I found the point you're talking about.
Linux is answering the ARP packets with Source Address 0.0.0.0 (see net/ipv4/arp.c):
/* Special case: IPv4 duplicate address detection packet (RFC2131) */
if (sip == 0) {
if (arp->ar_op == htons(ARPOP_REQUEST) &&
inet_addr_type(tip) == RTN_LOCAL)
arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr);
goto out;
}
Windows is checking for duplicate addresses using ARP packets with source _and_
destination address set to the address in question. So of course Linux won't answer it!
But I can't find a single word in the RFC2131 (http://www.faqs.org/rfcs/rfc2131.html)
saying that the Source Address _must_ set to 0.0.0.0!!!!
So the attached patch will make M$ Windows happy and APIPA working.
Thanks,
Steven
From: Gary Thomas <hidden> Date: 2003-08-12 13:56:55
I'm trying to build 2.6.0-test3 for some embedded boards and, as
reported before, there are compile problems. The attached patches
fix these, but also bring up some questions:
* How best to handle optional support? One of the patches fixes
a problem of a missing system call (sys_pciconfig_iobase). In
this case, the platform I was building for has no PCI, so it's
not configured in. The way I fixed it was to conditionalize
the syscall table. An alternate way would be to have a module
which is compiled if CONFIG_PCI is *not* set (or alternately
have arch/ppc/kernel/pci.c always be compiled and export the
appropriate functions that just return -ENOSYS). Comments?
* I have a number of boards/platforms that I support that have
not been moved into 2.6. Can I just send patches for those
as well?
* Has anyone succeeded in building & running 2.6 (or late 2.5)
on any embedded boards (8xx/8260/405)?
Thanks.
--
Gary Thomas [off-list ref]
MLB Associates
On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
* How best to handle optional support? One of the patches fixes
a problem of a missing system call (sys_pciconfig_iobase). In
this case, the platform I was building for has no PCI, so it's
not configured in. The way I fixed it was to conditionalize
the syscall table. An alternate way would be to have a module
which is compiled if CONFIG_PCI is *not* set (or alternately
have arch/ppc/kernel/pci.c always be compiled and export the
appropriate functions that just return -ENOSYS). Comments?
'cond_syscall' is _supposed_ to work here. But in this one case, it
does not. I've tried tracking this down a little bit, and the 'weak'
asm bits make it as far as the pci.s file, but not the pci.o. And to
make it all the more odd, if I threw the cond_syscall into a file in
kernel/ (just to try it out), it works.
* I have a number of boards/platforms that I support that have
not been moved into 2.6. Can I just send patches for those
as well?
In the same manner you did for 2.4, yes (logical patches, and preferably
against linux-2.5 (linux-2.6 now?) tree. If something is missing there
(it shouldn't be, but it could be :)) that is in linuxppc-2.5, either
move it over in another changeset, or bug myself / paul / ben.
* Has anyone succeeded in building & running 2.6 (or late 2.5)
on any embedded boards (8xx/8260/405)?
After looking at the similar code in drivers/serial, I don't think this
is sufficient. But I didn't dig too far into seee what c->data was
there.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2003-08-12 15:39:30
Steven Scholz wrote:
Windows is checking for duplicate addresses using ARP packets with
source _and_
destination address set to the address in question. So of course Linux
won't answer it!
But I can't find a single word in the RFC2131
(http://www.faqs.org/rfcs/rfc2131.html)
saying that the Source Address _must_ set to 0.0.0.0!!!!
I don't remember if it was in RFC2131 or RFC1541. RFC2131 is an updated
version of RFC1541, so I thought the words would still be there. In
any case it suggests as part of a DHCP the client tests to ensure the
address isn't already in use by sending a ARP using the sender hardware
address and setting the sender IP address to zero to avoid confusing
ARP caches in other hosts on the network. I don't remember the exact
words, but RFCs tend to be terse and concise in the area where you
need to pay attention to detail :-)
I'd suggest using the linux kernel or some networking mailing lists
to discuss this. I wouldn't apply this patch because it seems to be
wrong in the eyes of the RFCs, and I could never get it pushed into
the network portion of the source tree.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Gary Thomas <hidden> Date: 2003-08-12 15:40:20
On Tue, 2003-08-12 at 09:25, Tom Rini wrote:
On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
quoted
* How best to handle optional support? One of the patches fixes
a problem of a missing system call (sys_pciconfig_iobase). In
this case, the platform I was building for has no PCI, so it's
not configured in. The way I fixed it was to conditionalize
the syscall table. An alternate way would be to have a module
which is compiled if CONFIG_PCI is *not* set (or alternately
have arch/ppc/kernel/pci.c always be compiled and export the
appropriate functions that just return -ENOSYS). Comments?
'cond_syscall' is _supposed_ to work here. But in this one case, it
does not. I've tried tracking this down a little bit, and the 'weak'
asm bits make it as far as the pci.s file, but not the pci.o. And to
make it all the more odd, if I threw the cond_syscall into a file in
kernel/ (just to try it out), it works.
Which "pci.c"? The one in arch/ppc/kernel isn't even being compiled
in this case. Are you saying that it should (and behave differently
when CONFIG_PCI isn't set)?
quoted
* I have a number of boards/platforms that I support that have
not been moved into 2.6. Can I just send patches for those
as well?
In the same manner you did for 2.4, yes (logical patches, and preferably
against linux-2.5 (linux-2.6 now?) tree. If something is missing there
(it shouldn't be, but it could be :)) that is in linuxppc-2.5, either
move it over in another changeset, or bug myself / paul / ben.
OK.
quoted
* Has anyone succeeded in building & running 2.6 (or late 2.5)
on any embedded boards (8xx/8260/405)?
After looking at the similar code in drivers/serial, I don't think this
is sufficient. But I didn't dig too far into seee what c->data was
there.
It seems to be [virtually] the same as in
arch/ppc/8xx_io/uart.c
drivers/char/amiserial.c
drivers/char/serial_tx3912.c
drivers/char/sh-sci.c
drivers/macintosh/macserial.c
--
Gary Thomas [off-list ref]
MLB Associates
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Tue, Aug 12, 2003 at 09:40:20AM -0600, Gary Thomas wrote:
On Tue, 2003-08-12 at 09:25, Tom Rini wrote:
quoted
On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
quoted
* How best to handle optional support? One of the patches fixes
a problem of a missing system call (sys_pciconfig_iobase). In
this case, the platform I was building for has no PCI, so it's
not configured in. The way I fixed it was to conditionalize
the syscall table. An alternate way would be to have a module
which is compiled if CONFIG_PCI is *not* set (or alternately
have arch/ppc/kernel/pci.c always be compiled and export the
appropriate functions that just return -ENOSYS). Comments?
'cond_syscall' is _supposed_ to work here. But in this one case, it
does not. I've tried tracking this down a little bit, and the 'weak'
asm bits make it as far as the pci.s file, but not the pci.o. And to
make it all the more odd, if I threw the cond_syscall into a file in
kernel/ (just to try it out), it works.
Which "pci.c"? The one in arch/ppc/kernel isn't even being compiled
in this case. Are you saying that it should (and behave differently
when CONFIG_PCI isn't set)?
Too early in the AM. I meant arch/ppc/kernel/syscall.c (which is being
compiled) not arch/ppc/kernel/pci.c
quoted
quoted
* Has anyone succeeded in building & running 2.6 (or late 2.5)
on any embedded boards (8xx/8260/405)?
No / Yes / Yes.
^^^ How? These compile errors would prevent this.
'Late' 2.5. Before DaveM broke 8260_io/enet.c, and before the serial
change.
After looking at the similar code in drivers/serial, I don't think this
is sufficient. But I didn't dig too far into seee what c->data was
there.
It seems to be [virtually] the same as in
arch/ppc/8xx_io/uart.c
drivers/char/amiserial.c
drivers/char/serial_tx3912.c
drivers/char/sh-sci.c
drivers/macintosh/macserial.c
Those are all of the obsolete, and probably broken drivers.
drivers/serial is where all of the 'new' and working serial drivers are.
If you've got some time, the 8260 serial driver really should be
re-written as a driver inside of drivers/serial. :)
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Gary Thomas <hidden> Date: 2003-08-12 19:13:37
On Tue, 2003-08-12 at 09:46, Tom Rini wrote:
On Tue, Aug 12, 2003 at 09:40:20AM -0600, Gary Thomas wrote:
quoted
On Tue, 2003-08-12 at 09:25, Tom Rini wrote:
quoted
On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
quoted
* How best to handle optional support? One of the patches fixes
a problem of a missing system call (sys_pciconfig_iobase). In
this case, the platform I was building for has no PCI, so it's
not configured in. The way I fixed it was to conditionalize
the syscall table. An alternate way would be to have a module
which is compiled if CONFIG_PCI is *not* set (or alternately
have arch/ppc/kernel/pci.c always be compiled and export the
appropriate functions that just return -ENOSYS). Comments?
'cond_syscall' is _supposed_ to work here. But in this one case, it
does not. I've tried tracking this down a little bit, and the 'weak'
asm bits make it as far as the pci.s file, but not the pci.o. And to
make it all the more odd, if I threw the cond_syscall into a file in
kernel/ (just to try it out), it works.
Which "pci.c"? The one in arch/ppc/kernel isn't even being compiled
in this case. Are you saying that it should (and behave differently
when CONFIG_PCI isn't set)?
Too early in the AM. I meant arch/ppc/kernel/syscall.c (which is being
compiled) not arch/ppc/kernel/pci.c
I don't understand why either. I did note that this construct is not
used in any other platform/architecture code. For now, I'm using this
change (instead of the change to misc.S)
Index: arch/ppc/kernel/syscalls.c
===================================================================
RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/kernel/syscalls.c,v
retrieving revision 1.1
diff -u -5 -p -r1.1 syscalls.c
--- arch/ppc/kernel/syscalls.c 12 Aug 2003 12:18:16 -0000 1.1+++ arch/ppc/kernel/syscalls.c 12 Aug 2003 19:07:58 -0000
@@ -37,10 +37,12 @@#include<linux/unistd.h>#include<asm/uaccess.h>#include<asm/ipc.h>#include<asm/semaphore.h>+#undef cond_syscall+#define cond_syscall(x) asmlinkage long x() __attribute__((weak)); asmlinkage long x() { return -ENOSYS; }voidcheck_bugs(void){}
After looking at the similar code in drivers/serial, I don't think this
is sufficient. But I didn't dig too far into seee what c->data was
there.
It seems to be [virtually] the same as in
arch/ppc/8xx_io/uart.c
drivers/char/amiserial.c
drivers/char/serial_tx3912.c
drivers/char/sh-sci.c
drivers/macintosh/macserial.c
Those are all of the obsolete, and probably broken drivers.
drivers/serial is where all of the 'new' and working serial drivers are.
If you've got some time, the 8260 serial driver really should be
re-written as a driver inside of drivers/serial. :)
I'll look into this. Can you suggest a good driver to use as guidance?
--
Gary Thomas [off-list ref]
MLB Associates
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
After looking at the similar code in drivers/serial, I don't think this
is sufficient. But I didn't dig too far into seee what c->data was
there.
It seems to be [virtually] the same as in
arch/ppc/8xx_io/uart.c
drivers/char/amiserial.c
drivers/char/serial_tx3912.c
drivers/char/sh-sci.c
drivers/macintosh/macserial.c
Those are all of the obsolete, and probably broken drivers.
drivers/serial is where all of the 'new' and working serial drivers are.
If you've got some time, the 8260 serial driver really should be
re-written as a driver inside of drivers/serial. :)
I'll look into this. Can you suggest a good driver to use as guidance?
For the conversion? Not off-hand. But there should be some docs on how
to write these drivers on the ARM pages (RMK wrote this driver /
abstraction set), or just skim a few of the non-'core' files under
drivers/serial to see what's needed on the driver-specific part.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Wed, Aug 13, 2003 at 01:09:05AM +0200, Thomas Gleixner wrote:
On Tuesday 12 August 2003 23:54, Tom Rini wrote:
quoted
quoted
quoted
quoted
It seems to be [virtually] the same as in
arch/ppc/8xx_io/uart.c
drivers/char/amiserial.c
drivers/char/serial_tx3912.c
drivers/char/sh-sci.c
drivers/macintosh/macserial.c
Those are all of the obsolete, and probably broken drivers.
drivers/serial is where all of the 'new' and working serial drivers
are. If you've got some time, the 8260 serial driver really should be
re-written as a driver inside of drivers/serial. :)
I'll look into this. Can you suggest a good driver to use as guidance?
For the conversion? Not off-hand. But there should be some docs on how
to write these drivers on the ARM pages (RMK wrote this driver /
abstraction set), or just skim a few of the non-'core' files under
drivers/serial to see what's needed on the driver-specific part.
I have a nearly ready to use driver for MPC860, which uses driver/serial.c.
There is just an issue regarding startup, when the mmu is not up.
Maybe it can be helpful. It has support for configurable pins and flowcontrol.
If somebody is interrested, I can provide the code and some help to get it
running.
I'd be interested in looking at it. Do you have other patches to bring
MPC860 support for 2.6 up to date? Or is this using the 2.4 version of
drivers/serial?
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Thomas Gleixner <hidden> Date: 2003-08-12 23:09:05
On Tuesday 12 August 2003 23:54, Tom Rini wrote:
quoted
quoted
quoted
It seems to be [virtually] the same as in
arch/ppc/8xx_io/uart.c
drivers/char/amiserial.c
drivers/char/serial_tx3912.c
drivers/char/sh-sci.c
drivers/macintosh/macserial.c
Those are all of the obsolete, and probably broken drivers.
drivers/serial is where all of the 'new' and working serial drivers
are. If you've got some time, the 8260 serial driver really should be
re-written as a driver inside of drivers/serial. :)
I'll look into this. Can you suggest a good driver to use as guidance?
For the conversion? Not off-hand. But there should be some docs on how
to write these drivers on the ARM pages (RMK wrote this driver /
abstraction set), or just skim a few of the non-'core' files under
drivers/serial to see what's needed on the driver-specific part.
I have a nearly ready to use driver for MPC860, which uses driver/serial.c.
There is just an issue regarding startup, when the mmu is not up.
Maybe it can be helpful. It has support for configurable pins and flowcontrol.
If somebody is interrested, I can provide the code and some help to get it
running.
--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/