New: Appletalk packets are delivered to the last interface FD_SET
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): [email protected]/
(switching to email for netdev - please repond via emailed reply-to-all, not via the bugzilla UI)
Quoted 51 lines · On Thu, 15 Nov 2007 01:56:07 -0800 (PST) [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9384
Summary: Appletalk packets are delivered to the last interface FD_SET Product: Networking Version: 2.5 KernelVersion: 2.6.21.3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: [email protected] ReportedBy: [email protected]Most recent kernel where this bug did not occur: 2.6.10. Maybe 2.6.15? It was in 2.6.18 along with bug 7421 which caused me to disable netatalk until now.
Distribution: Debian etch (4.0)
Hardware Environment: Pentium 4 2.8GHz, HT off, Intel D865GLC motherboard, 256MB RAM, onboard Intel GigE, PCI Intel e100.
Software Environment: Netatalk 2.0.3, ipset patch for iptables and kernel Problem Description: Appletalk packets appear to come from the wrong interface, specifically the last oneFD_SET. Using wireshark I see Appletalk rtmp packets arrive from the upstream router on eth1 (the e100). Netatalk then reports the packet as having arrived on eth0.3, which is the only other appletalk enabled interface, and prints "rtmp_packetinterface mismatch" because the packet appears to come from the wrong interface.I'm fairly sure it's the kernel doing it, because wireshark is listening on eth1 and shows the packet from the upstream router's MAC address and DDP address, then the debug code in atalkd immediately after the recvfrom prints the
ifr_namewhich is eth0.3. Also netatalk 2.0.3 was released over 2 years ago, so the only code that's changed is the kernel.Enabling appletalk on eth0.2 clarifies the problem - packets are delivered to fds belonging to the last interface
FD_SET. Reordering the interfaces also shows this, as in the config file changing the order of the interfaces changes the order they're looped through forFD_SET.Steps to reproduce: Set up a multi-interface netatalk config and watch for
rtmp_packetinterface mismatch messages. I added a bunch of log statements to debug this, the most useful places to put them are at the end ofsetaddr()and after theselect()inmain().The machine is a router, so I have to minimise the downtime of testing different kernel versions. I am happy to instrument atalkd or provide packet captures.
David Miller
maintainerFrom: Andrew Morton <[email protected]>
Date: Thu, 15 Nov 2007 02:12:19 -0800
Quoted 24 lines
Quoted 24 lines
Most recent kernel where this bug did not occur: 2.6.10. Maybe 2.6.15? It was in 2.6.18 along with bug 7421 which caused me to disable netatalk until now.
Distribution: Debian etch (4.0)
Hardware Environment: Pentium 4 2.8GHz, HT off, Intel D865GLC motherboard, 256MB RAM, onboard Intel GigE, PCI Intel e100.
Software Environment: Netatalk 2.0.3, ipset patch for iptables and kernel Problem Description: Appletalk packets appear to come from the wrong interface, specifically the last oneFD_SET. Using wireshark I see Appletalk rtmp packets arrive from the upstream router on eth1 (the e100). Netatalk then reports the packet as having arrived on eth0.3, which is the only other appletalk enabled interface, and prints "rtmp_packetinterface mismatch" because the packet appears to come from the wrong interface.I'm fairly sure it's the kernel doing it, because wireshark is listening on eth1 and shows the packet from the upstream router's MAC address and DDP address, then the debug code in atalkd immediately after the recvfrom prints the
ifr_namewhich is eth0.3. Also netatalk 2.0.3 was released over 2 years ago, so the only code that's changed is the kernel.Enabling appletalk on eth0.2 clarifies the problem - packets are delivered to fds belonging to the last interface
FD_SET. Reordering the interfaces also shows this, as in the config file changing the order of the interfaces changes the order they're looped through forFD_SET.
Quoted 8 lines
Quoted 8 lines
Steps to reproduce: Set up a multi-interface netatalk config and watch for
rtmp_packetinterface mismatch messages. I added a bunch of log statements to debug this, the most useful places to put them are at the end ofsetaddr()and after theselect()inmain().The machine is a router, so I have to minimise the downtime of testing different kernel versions. I am happy to instrument atalkd or provide packet captures.
I suspect there is some issue with the ordering of the atalk interface list which is causing this.
Arnaldo, can you please take a look at this?
Thanks.
Em Thu, Nov 15, 2007 at 03:49:35PM -0800, David Miller escreveu:
Quoted 32 lines
From: Andrew Morton <[email protected]>
Date: Thu, 15 Nov 2007 02:12:19 -0800Quoted 29 lines
Quoted 29 lines
Most recent kernel where this bug did not occur: 2.6.10. Maybe 2.6.15? It was in 2.6.18 along with bug 7421 which caused me to disable netatalk until now.
Distribution: Debian etch (4.0)
Hardware Environment: Pentium 4 2.8GHz, HT off, Intel D865GLC motherboard, 256MB RAM, onboard Intel GigE, PCI Intel e100.
Software Environment: Netatalk 2.0.3, ipset patch for iptables and kernel Problem Description: Appletalk packets appear to come from the wrong interface, specifically the last oneFD_SET. Using wireshark I see Appletalk rtmp packets arrive from the upstream router on eth1 (the e100). Netatalk then reports the packet as having arrived on eth0.3, which is the only other appletalk enabled interface, and prints "rtmp_packetinterface mismatch" because the packet appears to come from the wrong interface.I'm fairly sure it's the kernel doing it, because wireshark is listening on eth1 and shows the packet from the upstream router's MAC address and DDP address, then the debug code in atalkd immediately after the recvfrom prints the
ifr_namewhich is eth0.3. Also netatalk 2.0.3 was released over 2 years ago, so the only code that's changed is the kernel.Enabling appletalk on eth0.2 clarifies the problem - packets are delivered to fds belonging to the last interface
FD_SET. Reordering the interfaces also shows this, as in the config file changing the order of the interfaces changes the order they're looped through forFD_SET.Steps to reproduce: Set up a multi-interface netatalk config and watch for
rtmp_packetinterface mismatch messages. I added a bunch of log statements to debug this, the most useful places to put them are at the end ofsetaddr()and after theselect()inmain().
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
The machine is a router, so I have to minimise the downtime of testing different kernel versions. I am happy to instrument atalkd or provide packet captures.
I suspect there is some issue with the ordering of the atalk interface list which is causing this.
Arnaldo, can you please take a look at this?
I'll look at this in the afternoon.
- Arnaldo