From owner-netdev@oss.sgi.com Fri Mar 1 10:50:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21Io6C00481 for netdev-outgoing; Fri, 1 Mar 2002 10:50:06 -0800 Received: from white.deltatee.com (red.deltatee.com [216.94.173.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21ImC900450 for ; Fri, 1 Mar 2002 10:48:12 -0800 Received: from amavis by white.deltatee.com with scanned-ok (Exim 3.34 #1 (Debian)) id 16grA9-0000EL-00; Fri, 01 Mar 2002 10:49:45 -0700 Received: from (deltatee.com) [172.16.1.101] (angusa) by white.deltatee.com with esmtp (Exim 3.34 #1 (Debian)) id 16grA7-0000E7-00; Fri, 01 Mar 2002 10:49:43 -0700 Message-ID: <3C7FBF36.4090501@deltatee.com> Date: Fri, 01 Mar 2002 10:49:42 -0700 From: Angus Ainslie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Kernel oops in ip_route_input Content-Type: multipart/mixed; boundary="------------050306050900010405000201" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-netdev@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------050306050900010405000201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, This kernel crash happens about once every two hours. We're also currently having a problem with apache-ssl 1.3 SIGSEGVing. The crash seems to be exacerbated by a login via ssh from putty. My network card is a DFE-530TX+. Here are my tables and routes: gold{root}~#iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination gold{root}~#route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 216.94.173.216 * 255.255.255.248 U 0 0 0 eth0 172.16.1.0 * 255.255.255.0 U 0 0 0 eth0 default red.priv.deltat 0.0.0.0 UG 0 0 0 eth0 gold{root}~# Thanks Angus --------------050306050900010405000201 Content-Type: text/plain; name="config-2.4.16.server" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config-2.4.16.server" # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set CONFIG_M586TSC=y # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_USE_STRING_486=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_CARDBUS=y # CONFIG_I82092 is not set CONFIG_I82365=y CONFIG_TCIC=y # # PCI Hotplug Support # CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y CONFIG_NETLINK=y CONFIG_IP_MULTIPLE_TABLES=y # CONFIG_IP_ROUTE_FWMARK is not set CONFIG_IP_ROUTE_NAT=y # CONFIG_IP_ROUTE_MULTIPATH is not set # CONFIG_IP_ROUTE_TOS is not set # CONFIG_IP_ROUTE_VERBOSE is not set # CONFIG_IP_ROUTE_LARGE_TABLES is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y # CONFIG_IP_PNP_BOOTP is not set # CONFIG_IP_PNP_RARP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_NET_IPGRE_BROADCAST is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_INET_ECN=y CONFIG_INET_ECN_DISABLED=y CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_NAT_NEEDED=y # CONFIG_IP_NF_COMPAT_IPFWADM is not set CONFIG_IPV6=m # # IPv6: Netfilter Configuration # # CONFIG_IP6_NF_IPTABLES is not set CONFIG_KHTTPD=m # CONFIG_ATM is not set CONFIG_VLAN_8021Q=m # CONFIG_IPX is not set CONFIG_ATALK=m # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set CONFIG_NET_HW_FLOWCONTROL=y # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set CONFIG_BLK_DEV_ALI15X3=y # CONFIG_WDC_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y # CONFIG_AMD74XX_OVERRIDE is not set CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_CY82C693=y # CONFIG_BLK_DEV_CS5530 is not set CONFIG_BLK_DEV_HPT34X=y # CONFIG_HPT34X_AUTODMA is not set CONFIG_BLK_DEV_HPT366=y CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_PDC202XX=y CONFIG_PDC202XX_BURST=y CONFIG_PDC202XX_FORCE=y CONFIG_BLK_DEV_SVWKS=y CONFIG_BLK_DEV_SIS5513=y CONFIG_BLK_DEV_SLC90E66=y # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # # SCSI support # CONFIG_SCSI=m CONFIG_BLK_DEV_SD=m CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=m CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_7000FASST=m CONFIG_SCSI_ACARD=m CONFIG_SCSI_AHA152X=m CONFIG_SCSI_AHA1542=m CONFIG_SCSI_AHA1740=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=253 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set CONFIG_SCSI_AIC7XXX_OLD=m # CONFIG_AIC7XXX_OLD_TCQ_ON_BY_DEFAULT is not set CONFIG_AIC7XXX_OLD_CMDS_PER_DEVICE=8 # CONFIG_AIC7XXX_OLD_PROC_STATS is not set CONFIG_SCSI_DPT_I2O=m CONFIG_SCSI_ADVANSYS=m CONFIG_SCSI_IN2000=m CONFIG_SCSI_AM53C974=m CONFIG_SCSI_MEGARAID=m CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set CONFIG_SCSI_CPQFCTS=m CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_DTC3280=m CONFIG_SCSI_EATA=m # CONFIG_SCSI_EATA_TAGGED_QUEUE is not set # CONFIG_SCSI_EATA_LINKED_COMMANDS is not set CONFIG_SCSI_EATA_MAX_TAGS=16 CONFIG_SCSI_EATA_DMA=m CONFIG_SCSI_EATA_PIO=m CONFIG_SCSI_FUTURE_DOMAIN=m CONFIG_SCSI_GDTH=m CONFIG_SCSI_GENERIC_NCR5380=m # CONFIG_SCSI_GENERIC_NCR53C400 is not set CONFIG_SCSI_G_NCR5380_PORT=y # CONFIG_SCSI_G_NCR5380_MEM is not set CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m CONFIG_SCSI_INIA100=m # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set CONFIG_SCSI_NCR53C406A=m CONFIG_SCSI_NCR53C7xx=m # CONFIG_SCSI_NCR53C7xx_sync is not set # CONFIG_SCSI_NCR53C7xx_FAST is not set # CONFIG_SCSI_NCR53C7xx_DISCONNECT is not set CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set CONFIG_SCSI_NCR53C8XX=m CONFIG_SCSI_SYM53C8XX=m CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=20 # CONFIG_SCSI_NCR53C8XX_PROFILE is not set # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set # CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set # CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set CONFIG_SCSI_PAS16=m CONFIG_SCSI_PCI2000=m CONFIG_SCSI_PCI2220I=m CONFIG_SCSI_PSI240I=m CONFIG_SCSI_QLOGIC_FAS=m CONFIG_SCSI_QLOGIC_ISP=m CONFIG_SCSI_QLOGIC_FC=m # CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_SEAGATE=m CONFIG_SCSI_SIM710=m CONFIG_SCSI_SYM53C416=m CONFIG_SCSI_DC390T=m # CONFIG_SCSI_DC390T_NOGENSUPP is not set CONFIG_SCSI_T128=m CONFIG_SCSI_U14_34F=m # CONFIG_SCSI_U14_34F_LINKED_COMMANDS is not set CONFIG_SCSI_U14_34F_MAX_TAGS=8 CONFIG_SCSI_ULTRASTOR=m # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_SCSI_PCMCIA is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set # # Appletalk devices # CONFIG_APPLETALK=y # CONFIG_LTPC is not set # CONFIG_COPS is not set CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set CONFIG_HAPPYMEAL=m # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNLANCE is not set CONFIG_SUNGEM=m CONFIG_NET_VENDOR_3COM=y CONFIG_EL1=m CONFIG_EL2=m CONFIG_ELPLUS=m CONFIG_EL16=m CONFIG_EL3=m CONFIG_3C515=m # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=m CONFIG_LANCE=m # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set CONFIG_DEPCA=m CONFIG_HP100=m CONFIG_NET_ISA=y # CONFIG_E2100 is not set # CONFIG_EWRK3 is not set # CONFIG_EEXPRESS is not set # CONFIG_EEXPRESS_PRO is not set # CONFIG_HPLAN_PLUS is not set # CONFIG_HPLAN is not set # CONFIG_LP486E is not set # CONFIG_ETH16I is not set CONFIG_NE2000=m CONFIG_NET_PCI=y CONFIG_PCNET32=m # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set CONFIG_DE4X5=m # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139CP is not set CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set CONFIG_VIA_RHINE=m # CONFIG_VIA_RHINE_MMIO is not set CONFIG_WINBOND_840=m # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m # CONFIG_PPPOE is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y CONFIG_STRIP=m CONFIG_WAVELAN=m CONFIG_ARLAN=m CONFIG_AIRONET4500=m CONFIG_AIRONET4500_NONCS=m CONFIG_AIRONET4500_PNP=y CONFIG_AIRONET4500_PCI=y # CONFIG_AIRONET4500_ISA is not set # CONFIG_AIRONET4500_I365 is not set CONFIG_AIRONET4500_PROC=m CONFIG_AIRO=m CONFIG_HERMES=m CONFIG_PLX_HERMES=m CONFIG_PCMCIA_HERMES=m CONFIG_AIRO_CS=m CONFIG_NET_WIRELESS=y # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # CONFIG_NET_PCMCIA=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set CONFIG_PCMCIA_PCNET=m # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_PCMCIA_XIRC2PS is not set CONFIG_PCMCIA_AXNET=m # CONFIG_ARCNET_COM20020_CS is not set # CONFIG_PCMCIA_IBMTR is not set CONFIG_PCMCIA_XIRCOM=m # CONFIG_PCMCIA_XIRTULIP is not set CONFIG_NET_PCMCIA_RADIO=y CONFIG_PCMCIA_RAYCS=m CONFIG_PCMCIA_NETWAVE=m CONFIG_PCMCIA_WAVELAN=m CONFIG_AIRONET4500_CS=m # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # CONFIG_IRDA=m CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set # CONFIG_IRDA_OPTIONS is not set # # Infrared-port device drivers # # CONFIG_IRTTY_SIR is not set CONFIG_IRPORT_SIR=m CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_USB_IRDA=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # # CONFIG_INPUT is not set # CONFIG_INPUT_KEYBDEV is not set # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_INTEL_RNG=y CONFIG_NVRAM=m CONFIG_RTC=m # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # PCMCIA character devices # # CONFIG_PCMCIA_SERIAL_CS is not set CONFIG_MWAVE=m # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=m # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set # CONFIG_TMPFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_INTERMEZZO_FS=m CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set CONFIG_ZISOFS_FS=m CONFIG_ZLIB_FS_INFLATE=m # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # # CONFIG_SOUND is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set CONFIG_USB_LONG_TIMEOUT=y CONFIG_USB_UHCI=m CONFIG_USB_UHCI_ALT=m CONFIG_USB_OHCI=m # CONFIG_USB_AUDIO is not set CONFIG_USB_BLUETOOTH=m # CONFIG_USB_STORAGE is not set # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set CONFIG_USB_ACM=m # CONFIG_USB_PRINTER is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set CONFIG_USB_PEGASUS=m CONFIG_USB_KAWETH=m CONFIG_USB_CATC=m CONFIG_USB_CDCETHER=m CONFIG_USB_USBNET=m # CONFIG_USB_USS720 is not set # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OMNINET=m # CONFIG_USB_RIO500 is not set # # Bluetooth support # CONFIG_BLUEZ=m CONFIG_BLUEZ_L2CAP=m # # Bluetooth device drivers # CONFIG_BLUEZ_HCIUSB=m CONFIG_BLUEZ_HCIUART=m CONFIG_BLUEZ_HCIVHCI=m # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set --------------050306050900010405000201 Content-Type: text/plain; name="oops_trace.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="oops_trace.txt" ksymoops 2.4.3 on i586 2.4.16. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.16/ (default) -m /boot/System.map-2.4.16 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): ksyms_base symbol pci_hp_change_slot_info_R__ver_pci_hp_change_slot_info not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol pci_hp_deregister_R__ver_pci_hp_deregister not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol pci_hp_register_R__ver_pci_hp_register not found in System.map. Ignoring ksyms_base entry Unable to handle kernel paging request at virtual address 0d0110ac c01d2581 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: 00000583 ebx: d6890410 ecx: 650110fc edx: d362f480 esi: 00000002 edi: 0d0110ac ebp: 650110ac esp: c2d41f20 ds: 0018 es: 0018 ss: 0018 Process apache-ssl (pid: 891, stackpage=c2d41000) Stack: d6890400 d4f079a0 c002e340 c002e340 c01d43b7 c002e340 0d0110ac 650110ac 00000010 d6890400 00000000 c002e340 c002e340 d6890400 d6890400 c01ca12d c002e340 d6890400 c025ed84 00000001 c02975d0 fffffffb c02975c0 0000012b Call Trace: [] [] [] [] [] Code: 75 2d 38 9a 8c 00 00 00 75 25 a1 04 f9 29 c0 89 42 18 ff 42 >>EIP; c01d2580 <===== Trace; c01d43b6 Trace; c01ca12c Trace; c0114fba Trace; c0107f6c Trace; c0109d08 Code; c01d2580 00000000 <_EIP>: Code; c01d2580 <===== 0: 75 2d jne 2f <_EIP+0x2f> c01d25ae <===== Code; c01d2582 2: 38 9a 8c 00 00 00 cmp %bl,0x8c(%edx) Code; c01d2588 8: 75 25 jne 2f <_EIP+0x2f> c01d25ae Code; c01d258a a: a1 04 f9 29 c0 mov 0xc029f904,%eax Code; c01d258e f: 89 42 18 mov %eax,0x18(%edx) Code; c01d2592 12: ff 42 00 incl 0x0(%edx) <0>Kernel panic: Aiee, killing interrupt handler! 4 warnings issued. Results may not be reliable. --------------050306050900010405000201-- From owner-netdev@oss.sgi.com Fri Mar 1 11:08:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21J8Ox01008 for netdev-outgoing; Fri, 1 Mar 2002 11:08:24 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21J8L901005 for ; Fri, 1 Mar 2002 11:08:21 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id BBAB01EF6E; Fri, 1 Mar 2002 19:08:15 +0100 (MET) Date: Fri, 1 Mar 2002 19:08:15 +0100 From: Andi Kleen To: Angus Ainslie Cc: netdev@oss.sgi.com Subject: Re: Kernel oops in ip_route_input Message-ID: <20020301190815.A13389@wotan.suse.de> References: <3C7FBF36.4090501@deltatee.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C7FBF36.4090501@deltatee.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk > Code; c01d2580 <===== > 0: 75 2d jne 2f <_EIP+0x2f> c01d25ae <===== > Code; c01d2582 > 2: 38 9a 8c 00 00 00 cmp %bl,0x8c(%edx) > Code; c01d2588 > 8: 75 25 jne 2f <_EIP+0x2f> c01d25ae > Code; c01d258a > a: a1 04 f9 29 c0 mov 0xc029f904,%eax > Code; c01d258e > f: 89 42 18 mov %eax,0x18(%edx) > Code; c01d2592 > 12: ff 42 00 incl 0x0(%edx) The oops does not look correctly decoded. Could you decode it again with the correct kernel image? -Andi From owner-netdev@oss.sgi.com Sat Mar 2 17:08:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2318bD06327 for netdev-outgoing; Sat, 2 Mar 2002 17:08:37 -0800 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2318L906324 for ; Sat, 2 Mar 2002 17:08:22 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id g2328AH16690; Sun, 3 Mar 2002 02:08:10 GMT Date: Sun, 3 Mar 2002 02:08:10 +0000 (GMT) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: kuznet@ms2.inr.ac.ru cc: netdev@oss.sgi.com, Andi Kleen Subject: Re: OOPS: Multipath routing 2.4.17 In-Reply-To: <200203021436.RAA20557@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, Moved from lk to netdev On Sat, 2 Mar 2002 kuznet@ms2.inr.ac.ru wrote: > I remember your approach had some inacceptable issues, but 2.5 is exactly > the place to resolve them. :-) > > But actually I would like to see a fix for 2.4 for beginning. OK, I tested the appended patch (2.4.18) on UP, the scheduler works correctly. Use it (if needed at all) in kernel 2.4/2.5, where appropriate. The features: - "slow start" (nh_power=0) for each newly marked alive nexthop (starts on the next round), as before - nh_power protected from fib_multipath_lock - constant distribution - shorter - not sure for the speed, though, the modern CPUs divide faster and faster > Alexey Regards -- Julian Anastasov --- net/ipv4/fib_semantics.c.orig Sun Mar 3 00:24:47 2002 +++ net/ipv4/fib_semantics.c Sat Mar 2 21:57:27 2002 @@ -48,6 +48,7 @@ static struct fib_info *fib_info_list; static rwlock_t fib_info_lock = RW_LOCK_UNLOCKED; int fib_info_cnt; +static spinlock_t fib_multipath_lock = SPIN_LOCK_UNLOCKED; #define for_fib_info() { struct fib_info *fi; \ for (fi = fib_info_list; fi; fi = fi->fib_next) @@ -868,10 +869,6 @@ else if (nh->nh_dev == dev && nh->nh_scope != scope) { nh->nh_flags |= RTNH_F_DEAD; -#ifdef CONFIG_IP_ROUTE_MULTIPATH - fi->fib_power -= nh->nh_power; - nh->nh_power = 0; -#endif dead++; } } endfor_nexthops(fi) @@ -931,44 +928,38 @@ void fib_select_multipath(const struct rt_key *key, struct fib_result *res) { struct fib_info *fi = res->fi; - int w; - - if (fi->fib_power <= 0) { - int power = 0; - change_nexthops(fi) { - if (!(nh->nh_flags&RTNH_F_DEAD)) { - power += nh->nh_weight; - nh->nh_power = nh->nh_weight; - } - } endfor_nexthops(fi); - fi->fib_power = power; -#if 1 - if (power <= 0) { - printk(KERN_CRIT "impossible 777\n"); - return; - } -#endif - } + int w = -1, sel = 0; + spin_lock_bh(&fib_multipath_lock); - /* w should be random number [0..fi->fib_power-1], - it is pretty bad approximation. - */ - - w = jiffies % fi->fib_power; + repeat: change_nexthops(fi) { - if (!(nh->nh_flags&RTNH_F_DEAD) && nh->nh_power) { - if ((w -= nh->nh_power) <= 0) { - nh->nh_power--; - fi->fib_power--; - res->nh_sel = nhsel; - return; - } + if (nh->nh_power > w && !(nh->nh_flags&RTNH_F_DEAD)) { + w = nh->nh_power; + sel = nhsel; } } endfor_nexthops(fi); + if (w > 0) { + fi->fib_nh[sel].nh_power--; + spin_unlock_bh(&fib_multipath_lock); + res->nh_sel = sel; + return; + } + + if (!w) { + change_nexthops(fi) { + if (!(nh->nh_flags&RTNH_F_DEAD)) + nh->nh_power = nh->nh_weight; + } endfor_nexthops(fi); + w = -1; + goto repeat; + } + + spin_unlock_bh(&fib_multipath_lock); #if 1 + /* Probably all nexthops are dead */ printk(KERN_CRIT "impossible 888\n"); #endif return; From owner-netdev@oss.sgi.com Sat Mar 2 17:21:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g231Lui06605 for netdev-outgoing; Sat, 2 Mar 2002 17:21:56 -0800 Received: from trillium-hollow.org (trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g231Lk906601 for ; Sat, 2 Mar 2002 17:21:46 -0800 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.33 #1) id 16hJki-0000rY-00; Sat, 02 Mar 2002 16:21:24 -0800 To: Julian Anastasov , Alan Cox cc: Szekeres Bela , Daniel Gryniewicz , linux-kernel , netdev@oss.sgi.com Subject: Re: Network Security hole (was -> Re: arp bug ) In-Reply-To: Your message of "Sun, 03 Mar 2002 00:46:12 GMT." Date: Sat, 02 Mar 2002 16:21:24 -0800 From: erich@uruk.org Message-Id: Sender: owner-netdev@oss.sgi.com Precedence: bulk [followons after this should probably go to "netdev@oss.sgi.com" and not the kernel list] Julian Anastasov wrote: > On Sat, 2 Mar 2002, Alan Cox wrote: > > > > behavior causes some problems for setups with rp_filter protection > > > and interfaces attached to same hub. If you want to find the reason > > > for this, here it is: > > > > rp_filter is an add on - not exactly default standards behaviour. If you > > want to make the case that rp_filter = 2 means apply a both way rule then > > I've personally no problem with that argument > > The rp_filter value of 2 is not support from Linux and > after reading the "5.3.8 Source Address Validation" paragraph > from rfc1812 it seems rp_filter 1 covers it. What exactly do > you mean by value of 2? Note that the remote box does not want to > spoof, it was directed from BOX1 to a wrong MAC where the traffic is > spoofed, the remote hosts are not guilty. They connect to the MAC we > provide by broadcasts. > > To Erich, rfc1812, 5.3.8 Source Address Validation: > > If this feature is implemented, it MUST be disabled by default That's not what I was talking about. I'm talking about Destination Address Validation based on the network you're getting the packet from, before it's passed on up to the protocol layers to the application. This is, frankly, the most important part for determining if you want to firewall off a packet from the wrong place. And if you don't have routing set up in your machine, I still kind of think it's an end-user box. The fact that the routing layer and application layers of Linux's TCP/IP stack are one and the same is a difficulty here which the IP firewalling code in Linux does not fix. I.e. if I wanted to have routing as well, but not accept any packets internally *not* destined for my interface, I'm not sure how to specify it without something like TCP wrappers, as sleazy as they can be, and they don't offer this kind of capability in general as is. I have been sniffing through the RFCs (and my trusty copy of TCP/IP Illustrated Vol 1), and while no guru on these issues, have found nothing specififying that a non-router must accept packets that have the wrong destination address. In fact, there are several places that make it clear that hosts (as opposed to routers) must not forward packets. I assume they're talking about a host not accidentally confusing routers by moving packets from one network to another without having routes programmed, but that language is *still* relevant in the case when a packet is received by the wrong interface. It should not be arbitrarily forwarding them internally to different interfaces without being told to. I think that is a standards-based reason to change the default behavior. If you need proof, I can look up the part saying that hosts must never forward packets unless explicitly commanded to, and the interpretation that if they are asked to they must refuse should be sufficient. Also, if I'm understanding this language correctly, hosts and routers are distinctly not the same, and RFC 1812 is talking about routers. It's possible I'm not understanding the language correctly though, as I'm not deeply familiar with the IP RFCs by any means. -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-netdev@oss.sgi.com Sat Mar 2 17:34:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g231YBo06769 for netdev-outgoing; Sat, 2 Mar 2002 17:34:11 -0800 Received: from caramon.arm.linux.org.uk (www.deepbluesolutions.co.uk [212.18.232.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g231Y7906765 for ; Sat, 2 Mar 2002 17:34:07 -0800 Received: from [3ffe:8260:2002:1:201:2ff:fe14:8fad] (helo=flint.arm.linux.org.uk) by caramon.arm.linux.org.uk with esmtp (Exim 3.16 #1) id 16hJwl-0007Gj-00; Sun, 03 Mar 2002 00:33:51 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 3.16 #1) id 16hJwl-00045i-00; Sun, 03 Mar 2002 00:33:51 +0000 Date: Sun, 3 Mar 2002 00:33:51 +0000 From: Russell King To: erich@uruk.org Cc: Julian Anastasov , Alan Cox , Szekeres Bela , Daniel Gryniewicz , linux-kernel , netdev@oss.sgi.com Subject: Re: Network Security hole (was -> Re: arp bug ) Message-ID: <20020303003351.B6120@flint.arm.linux.org.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from erich@uruk.org on Sat, Mar 02, 2002 at 04:21:24PM -0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sat, Mar 02, 2002 at 04:21:24PM -0800, erich@uruk.org wrote: > The fact that the routing layer and application layers of Linux's > TCP/IP stack are one and the same is a difficulty here which the > IP firewalling code in Linux does not fix. I.e. if I wanted to > have routing as well, but not accept any packets internally *not* > destined for my interface, I'm not sure how to specify it without > something like TCP wrappers, as sleazy as they can be, and they > don't offer this kind of capability in general as is. Linux 2.4 netfilter: Incoming Outgoing interface interface ----+------------------- FORWARD -----------------+-------> | ^ v | INPUT -------------> Application -----------> OUTPUT The names in capitals are the names of the tables. You can control packets that the local machine sees completely independently of what gets routed through the machine with a kernel supporting iptables by adding the appropriate rules to the input and forward tables. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From owner-netdev@oss.sgi.com Sat Mar 2 18:25:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g232Pwm07404 for netdev-outgoing; Sat, 2 Mar 2002 18:25:58 -0800 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g232Pn907401 for ; Sat, 2 Mar 2002 18:25:50 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id g233POH17408; Sun, 3 Mar 2002 03:25:24 GMT Date: Sun, 3 Mar 2002 03:25:24 +0000 (GMT) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: erich@uruk.org cc: Alan Cox , Szekeres Bela , Daniel Gryniewicz , Subject: Re: Network Security hole (was -> Re: arp bug ) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, On Sat, 2 Mar 2002 erich@uruk.org wrote: > That's not what I was talking about. I'm talking about > Destination Address Validation based on the network you're getting > the packet from, before it's passed on up to the protocol layers > to the application. :) You want to restrict the access to one device. Use firewall rules. > This is, frankly, the most important part for determining if you > want to firewall off a packet from the wrong place. And if you Think different: - the hosts have unique IPs - in most of the cases you don't need to bind somehow the traffic to device at application layer, you can use the paths provided from routes - if you have many paths to one remote IP you can try to distinguish them by more specific routes specifying selection for the source addresses or to use alternative routes with failover/balancing capability So, the source validation is enough to catch packets from worng place and additionally can provide the ability to use many interfaces for incoming/outgoing traffic. > IP firewalling code in Linux does not fix. I.e. if I wanted to > have routing as well, but not accept any packets internally *not* > destined for my interface, I'm not sure how to specify it without You can do it aslo by using more specific rules, for example: ip rule add from local_restricted_ip to each_allowed_remote_net table 100 ip route add each_allowed_remote_net [via XXX] dev XXX src XXX table 100 Such rules restrict the traffic between the local and remote net only through one device, something similar to the restriction provided from ISPs: if you are connected to 2 ISPs with distinct networks you have to use such specific rules to allow packets from universe to come only from their respective interface, same for the in->out traffic. Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Sat Mar 2 18:33:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g232XdS07658 for netdev-outgoing; Sat, 2 Mar 2002 18:33:39 -0800 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g232XZ907655 for ; Sat, 2 Mar 2002 18:33:35 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id g233XPH17489; Sun, 3 Mar 2002 03:33:25 GMT Date: Sun, 3 Mar 2002 03:33:25 +0000 (GMT) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: erich@uruk.org cc: netdev@oss.sgi.com Subject: Re: Network Security hole (was -> Re: arp bug ) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sat, 2 Mar 2002 erich@uruk.org wrote: > That's not what I was talking about. I'm talking about > Destination Address Validation based on the network you're getting Forgot to mention, the rp_filter does not check only the source IPs, it uses saddr, daddr and tos. So, you have full validation, just use the more specific rules+routes. Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Sat Mar 2 18:48:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g232mvw07887 for netdev-outgoing; Sat, 2 Mar 2002 18:48:57 -0800 Received: from trillium-hollow.org (trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g232mq907884 for ; Sat, 2 Mar 2002 18:48:52 -0800 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.33 #1) id 16hL77-00014k-00; Sat, 02 Mar 2002 17:48:37 -0800 To: Julian Anastasov cc: Alan Cox , Szekeres Bela , Daniel Gryniewicz , netdev@oss.sgi.com Subject: Re: Network Security hole (was -> Re: arp bug ) In-Reply-To: Your message of "Sun, 03 Mar 2002 03:25:24 GMT." Date: Sat, 02 Mar 2002 17:48:37 -0800 From: erich@uruk.org Message-Id: Sender: owner-netdev@oss.sgi.com Precedence: bulk Julian Anastasov wrote: > On Sat, 2 Mar 2002 erich@uruk.org wrote: > > > That's not what I was talking about. I'm talking about > > Destination Address Validation based on the network you're getting > > the packet from, before it's passed on up to the protocol layers > > to the application. > > :) You want to restrict the access to one device. > Use firewall rules. Well, I'm arguing for default behavior here of the ARP and acceptance of packets to interfaces. I agree that, if you want exotic effects, you can do whatever you want. Given my argument about the standard interpretation, I think that it's reasonable to have, for default behavior, what people would expect to happen. Why make it work for people to bulletproof Linux in relatively simple configurations? > > This is, frankly, the most important part for determining if you > > want to firewall off a packet from the wrong place. And if you > > Think different: ... Er, you're talking about more exotic stuff. I'm talking simply the determination: Is the host from physically inside or outside of your network? Anyone can craft packets to look like whatever they want if the machine is close enough to you on the network (esp. if they're on the same switched subnet, say). This is a real thing you see often enough nowadays with Wireless networks that have been dropped just outside of firewalls because WEP encryption is broken. So, just the simple protection of: If I don't enable the "accept packets from any interface for any other interface" mode, then act like the network is distinct and validated to be so for each interface, with no bleed-over. Heck, you might even want specific iptables or somesuch capabilities to explicitly allow that kind of internal routing to the interfaces and application layer. -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-netdev@oss.sgi.com Sun Mar 3 02:50:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23AoBL12315 for netdev-outgoing; Sun, 3 Mar 2002 02:50:11 -0800 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23Anq912309 for ; Sun, 3 Mar 2002 02:49:52 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id g23BnBv01296; Sun, 3 Mar 2002 11:49:11 GMT Date: Sun, 3 Mar 2002 11:49:11 +0000 (GMT) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: erich@uruk.org cc: Alan Cox , Szekeres Bela , Daniel Gryniewicz , Subject: Re: Network Security hole (was -> Re: arp bug ) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, On Sat, 2 Mar 2002 erich@uruk.org wrote: > Well, I'm arguing for default behavior here of the ARP and acceptance > of packets to interfaces. I agree that, if you want exotic effects, > you can do whatever you want. Note that ARP works as expected: it uses the routing. The ARP code restricts the ARP traffic to the same route path as the IP traffic. Example: - rp_filter=0: we receive any IP traffic on this iface (it is default, as the standards prescribe) and we send traffic to one network through one iface. Same for ARP. In the case that you worry you have rp_filter=0 and the ARP probes are replyed on all devices attached to the same medium because the routing does not drop the probe. In short, the default mode is "receive any traffic on each iface", you have the bare minimum to play with IP. It is hard to say without user help which iface is external and which is internal. This is the default Linux mode. Note that the default distro mode may differ. There are distros used in different context: security only (a firewall/router/VPN box), etc - rp_filter=1: we receive only allowed traffic on this iface and send IP traffic only through the same iface. Same for ARP. Achievable only by defining IP address or route on iface. No fancy routing, no ip rules, just routes. Note that the ip rules matching specific source IPs play when you have many paths to same destination. I too prefer the default behavior to be rp_filter=1 because it is easier for me but my experience shows that the problems can come from everywhere. One real example for you: Linux border gateway where your security mode simply does not work (I'm even not sure whether it works for border gateways at all, can you give one example for setup where the searching of iph->daddr in the list of IPs on the receiving iface works): Universe | ISP 10.0.0.1/24 | |ADSL | |eth0, proxy_arp, rp_filter, host and default route via .1 LINUX_BOX bastion |eth1, proxy_arp, rp_filter, ifconfig 10.0.0.2 | HUB | 10.0.0.3/24 10.0.0.4/24 --------+------------+---------------+----- ... We have a secure box acting as transparent proxy for the public subnet 10.0.0.0/24. We are router (.2) and .1 is default gateway for all hosts and for our gateway. The ISP has IP .1 from our public net. The question: how Universe will talk with 10.0.0.3 or 10.0.0.2 if eth0 from our router does not have any IP from 10.0.0.0/24 network? If you are talking about the router/end-hosts differentiation, the answer is simple: the end-hosts use routers which provide security. We don't add explicitly IP to talk with the universe, we use one of the public IPs. For the directly attached networks use rp_filter and distinct targets on different ifaces with rp_filter protection. > Given my argument about the standard interpretation, I think that > it's reasonable to have, for default behavior, what people would > expect to happen. Why make it work for people to bulletproof > Linux in relatively simple configurations? May be because most of the Linux boxes work after firewall. May be you should start voting, whether Linux is mostly used for border gateway or as an internal box :)) In my experience the Linux newbies always use IP aliases, IPs from same subnet attached to many devices. Stupid, yes. But their efforts succeed in the default Linux mode. The security is so complex thing that it is difficult to define what should be the default behavior: be bastion? :) > Er, you're talking about more exotic stuff. I'm talking simply > the determination: Is the host from physically inside or outside > of your network? echo 1 > all/rp_filter echo 1 > eth0/rp_filter ifconfig eth0 192.168.0.1 This prescribes that the ARP and IP traffic from and to the 192.168.0.0/24 network will work only on this device, of course, if you set rp_filter=1 everywhere because if you set it to 0 on some iface this iface will accept any traffic - why not if this is an internal interface. So, the default behavior you are talking about, is achievable by setting rp_filter to 1 on all ifaces. > Anyone can craft packets to look like whatever they want if the machine > is close enough to you on the network (esp. if they're on the same > switched subnet, say). Yes, see again golden rule #2: if you put routes to many subnets on same iface you don't care whether they spoof, you put them in same security zone. They can impersonate to each other but not to anyone else reachable through different iface. When it comes to many hosts on same medium you can't be sure even for the hosts from same subnet, you don't know who exactly talks to you. If you are paranoid you can use only host routes, each on different iface. By this way you are sure the spoofing will not occur on per-host basis. You can even run IPSec on LAN :) > This is a real thing you see often enough nowadays with Wireless networks > that have been dropped just outside of firewalls because WEP encryption > is broken. I see but I don't think the solution for wireless is at routing layer. For LANs the problem with spoofing is solvable at physical and link layer, not above. Because the IP packets are generated freely. > So, just the simple protection of: If I don't enable the "accept packets > from any interface for any other interface" mode, then act like the network > is distinct and validated to be so for each interface, with no bleed-over. Use distro that have at boot: for i in */rp_filter; do echo 1 > $i ; done Nothing more is needed against spoofing. > Heck, you might even want specific iptables or somesuch capabilities to > explicitly allow that kind of internal routing to the interfaces and > application layer. No, you can completely avoid Netfilter and again to protect against spoofing and to be in the desired mode. Start to use Netfilter on per proto/port basis and to protect your services and clients because you can't use different iface for each host from universe. Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Sun Mar 3 02:54:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23AsIm12420 for netdev-outgoing; Sun, 3 Mar 2002 02:54:18 -0800 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23AsE912417 for ; Sun, 3 Mar 2002 02:54:15 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id g23Bs6v01321; Sun, 3 Mar 2002 11:54:12 GMT Date: Sun, 3 Mar 2002 11:54:06 +0000 (GMT) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: kuznet@ms2.inr.ac.ru cc: netdev@oss.sgi.com, Andi Kleen Subject: Re: OOPS: Multipath routing 2.4.17 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Sorry, DEAD does not need to be checked: > So, the new code must be something like this: } + if (force && nh->nh_dev == dev) { + dev_put(nh->nh_dev); + nh->nh_dev = NULL; + } } endfor_nexthops(fi) Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Sun Mar 3 06:35:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23EZ1A19709 for netdev-outgoing; Sun, 3 Mar 2002 06:35:01 -0800 Received: from tsmtp10.mail.isp (mailhost.teleline.es [195.235.113.141] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23EYu919706 for ; Sun, 3 Mar 2002 06:34:56 -0800 Received: from mitra.terra.es ([213.99.127.179]) by tsmtp10.mail.isp (Netscape Messaging Server 4.15 tsmtp10 Jul 26 2001 13:10:38) with ESMTP id GSEGDV01.Z7Z for ; Sun, 3 Mar 2002 14:34:43 +0100 Message-Id: <5.1.0.14.2.20020303142512.00bcb610@pop3.terra.es> X-Sender: fernando.anton.terra.es@pop3.terra.es X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 03 Mar 2002 14:34:31 +0100 To: netdev@oss.sgi.com From: Fernando Anton Subject: how do I get link layer addresses from user-space? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi all, I want to ask you a simple question that I don't get answered by myself: how can I get a network address resolver to a link-layer address by the kernel ? In other words... I have an user-space application which receives IPv4 and IPv6 packets to be routed, and I must tell what will be the next hop. Once I have the next hop (its IPv4 or IPv6 address) I will send it over a raw link-layer socket to the destination.. but I need to know its link-layer address to do it and.. I do not know how to get it. I've seen iproute2 sources and walked a little through ipneigh.c sources, but I have only found ways to set an ARP entry inside the kernel and to get the current ARP cache, but.. how do I trigger an ARP resolution in the kernel from userspace ? Thanks in advance Un saludo: Fernando Anton Alonso aka Mitra / Spanish Lords From owner-netdev@oss.sgi.com Sun Mar 3 15:02:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23N2Ei24878 for netdev-outgoing; Sun, 3 Mar 2002 15:02:14 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23N2B924874 for ; Sun, 3 Mar 2002 15:02:12 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id BE93E1E4A0; Sun, 3 Mar 2002 23:02:05 +0100 (MET) Date: Sun, 3 Mar 2002 23:02:05 +0100 From: Andi Kleen To: Fernando Anton Cc: netdev@oss.sgi.com Subject: Re: how do I get link layer addresses from user-space? Message-ID: <20020303230205.A1033@wotan.suse.de> References: <5.1.0.14.2.20020303142512.00bcb610@pop3.terra.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020303142512.00bcb610@pop3.terra.es> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, Mar 03, 2002 at 02:34:31PM +0100, Fernando Anton wrote: > how do I trigger an ARP resolution in the kernel from userspace ? Either by using a TCP/UDP/RAW socket or by implementing ARP yourself by hand. -Andi From owner-netdev@oss.sgi.com Mon Mar 4 17:31:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g251VVJ06099 for netdev-outgoing; Mon, 4 Mar 2002 17:31:31 -0800 Received: from angateway.acceleratednetworks.com ([12.44.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g251VS906095 for ; Mon, 4 Mar 2002 17:31:28 -0800 Received: from CALVIN.acceleratednetworks.com (calvin.acceleratednetworks.com [199.107.109.14]) by angateway.acceleratednetworks.com (8.8.8/8.8.8) with ESMTP id QAA26878 for ; Mon, 4 Mar 2002 16:21:43 -0800 (PST) Received: by CALVIN.acceleratednetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 16:26:02 -0800 Message-ID: <8B57A2E9423E844C911DF3BC5DB06E500FA0D7@CALVIN.acceleratednetworks.com> From: Shridhar Kulkarni To: "'netdev@oss.sgi.com'" Subject: NETLINK ARP DAEMON Date: Mon, 4 Mar 2002 16:25:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 469 Lines: 14 Hi, I need to implement a user-space ARP daemon for my application running on LINUX.. I saw references all over that you have developed something like NETLINK sockets implementation for manipulating ARP from user space. However I did find anywhere the source code for that. Is the source code for NETLINK ARP publicly available. I found the one for iproute2 but not for ARP.Can you please advise ? Regards, Shridhar Kulkarni. Accelerated Networks. 805-553-9680 x257 From owner-netdev@oss.sgi.com Mon Mar 4 18:17:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g252Heh06984 for netdev-outgoing; Mon, 4 Mar 2002 18:17:40 -0800 Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g252HX906978 for ; Mon, 4 Mar 2002 18:17:34 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id MAA31350; Tue, 5 Mar 2002 12:17:18 +1100 Date: Tue, 5 Mar 2002 12:17:18 +1100 (EST) From: James Morris To: Shridhar Kulkarni cc: "'netdev@oss.sgi.com'" Subject: Re: NETLINK ARP DAEMON In-Reply-To: <8B57A2E9423E844C911DF3BC5DB06E500FA0D7@CALVIN.acceleratednetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 619 Lines: 20 On Mon, 4 Mar 2002, Shridhar Kulkarni wrote: > Hi, > I need to implement a user-space ARP daemon for my application running on > LINUX.. I saw references all over that you have developed something like > NETLINK sockets implementation for manipulating ARP from user space. However > I did find anywhere the source code for that. Is the source code for NETLINK > ARP publicly available. I found the one for iproute2 but not for ARP.Can you > please advise ? Try a recent version of iproute2 (iproute2-2.4.7-now-ss020116-try) from ftp://ftp.inr.ac.ru/ip-routing/ - James -- James Morris From owner-netdev@oss.sgi.com Tue Mar 5 08:34:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25GYHR07585 for netdev-outgoing; Tue, 5 Mar 2002 08:34:17 -0800 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25GYC907578 for ; Tue, 5 Mar 2002 08:34:12 -0800 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g25FY6Q41789 for ; Tue, 5 Mar 2002 16:34:06 +0100 (CET) (envelope-from Atif.Syed@ccrle.nec.de) Received: from zark (zark.mobility.ccrle.nec.de [192.168.101.95]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id QAA19321 for ; Tue, 5 Mar 2002 16:34:05 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Atif Syed Organization: NEC To: netdev@oss.sgi.com Date: Tue, 5 Mar 2002 16:38:44 +0100 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02030516381400.00692@zark> Content-Transfer-Encoding: 8bit Subject: sending buffered packets in kernel! Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 931 Lines: 34 Hi everybody, I am doing kernel programming in IP-stack. I am facing problems bei sending packets. I receive 5 packets(udp-datagram) from other host. 1. I change the destination and source address of the same packet in ip6_rcv() in /usr/src/linux/net/ipv6/ip6_input.c and send it back. It works I have then written my own module, which is doing this job. I called my module_function in ip6_rcv. IMPORTANT part!!!!!! 2. I want to buffer for example 3 packets. When fourth one comes, all three packets together are sended. This is a problem!!! For this purpose I have chosen ip6_output.c. I call in my module a function called ip6_output(skb). This function is located in ip6_outout.c. My computer hangs. Am i going the right way or is there another possibility or i need to implement my own sending function? Thanks in advance -- Atif Syed NEC Europe Ltd. - Network Laboratories Email: Atif.Syed@ccrle.nec.de From owner-netdev@oss.sgi.com Tue Mar 5 10:39:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25Id9X13923 for netdev-outgoing; Tue, 5 Mar 2002 10:39:09 -0800 Received: from angateway.acceleratednetworks.com ([12.44.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25Id5913919 for ; Tue, 5 Mar 2002 10:39:05 -0800 Received: from CALVIN.acceleratednetworks.com (calvin.acceleratednetworks.com [199.107.109.14]) by angateway.acceleratednetworks.com (8.8.8/8.8.8) with ESMTP id JAA01705; Tue, 5 Mar 2002 09:28:27 -0800 (PST) Received: by CALVIN.acceleratednetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 09:32:46 -0800 Message-ID: <8B57A2E9423E844C911DF3BC5DB06E500FA0DB@CALVIN.acceleratednetworks.com> From: Shridhar Kulkarni To: "'James Morris'" Cc: "'netdev@oss.sgi.com'" Subject: RE: NETLINK ARP DAEMON Date: Tue, 5 Mar 2002 09:32:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 869 Lines: 32 no luck on the newer ip-routing version either..... -----Original Message----- From: James Morris [mailto:jmorris@intercode.com.au] Sent: Monday, March 04, 2002 5:17 PM To: Shridhar Kulkarni Cc: 'netdev@oss.sgi.com' Subject: Re: NETLINK ARP DAEMON On Mon, 4 Mar 2002, Shridhar Kulkarni wrote: > Hi, > I need to implement a user-space ARP daemon for my application running on > LINUX.. I saw references all over that you have developed something like > NETLINK sockets implementation for manipulating ARP from user space. However > I did find anywhere the source code for that. Is the source code for NETLINK > ARP publicly available. I found the one for iproute2 but not for ARP.Can you > please advise ? Try a recent version of iproute2 (iproute2-2.4.7-now-ss020116-try) from ftp://ftp.inr.ac.ru/ip-routing/ - James -- James Morris From owner-netdev@oss.sgi.com Wed Mar 6 07:28:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26FS3m20675 for netdev-outgoing; Wed, 6 Mar 2002 07:28:03 -0800 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26FRr920672 for ; Wed, 6 Mar 2002 07:27:53 -0800 Received: (qmail 11941 invoked by uid 2001); 6 Mar 2002 14:27:48 -0000 Date: Wed, 6 Mar 2002 15:27:48 +0100 From: Petr Baudis To: kuznet@ms2.inr.ac.ru Cc: roque@di.fc.ul.pt, pekkas@netcore.fi, netdev@oss.sgi.com, xs26-dev@xs26.net Subject: 'iptunnel change' can't change SIT tunnel endpoints Message-ID: <20020306142748.GM2198@pasky.ji.cz> Reply-To: xs26-dev@xs26.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.0i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 765 Lines: 22 Hello, we're having problems with 'iptunnel change' at linux 2.4.18 (non-usagi). When we try to change endpoints of the SIT tunnel, it always fails with ENOENT. I digged into the source a bit, but it looks this can only happen when changing endpoints of sit0, which is not the case here (the relevan code looks to reside at linux/ipv6/sit.c:646). And the code looks ok to me. Thanks in advance for any suggestion/help, -- Petr "Pasky" Baudis * elinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI hacker . "If you have acquired knowledge, what do you lack? If you lack knowledge, what have you acquired?" Lev. R. 1:6 . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From owner-netdev@oss.sgi.com Wed Mar 6 07:37:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26FblI20899 for netdev-outgoing; Wed, 6 Mar 2002 07:37:47 -0800 Received: from mxout2.netvision.net.il (mxout2.netvision.net.il [194.90.9.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Fbj920895 for ; Wed, 6 Mar 2002 07:37:45 -0800 Received: from nt-mail.radvision.com ([212.143.185.30]) by mxout2.netvision.net.il (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GSK00K7P3AQNU@mxout2.netvision.net.il> for netdev@oss.sgi.com; Wed, 06 Mar 2002 16:37:38 +0200 (IST) Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2650.21) id ; Wed, 06 Mar 2002 16:36:53 +0200 Content-return: allowed Date: Wed, 06 Mar 2002 16:36:45 +0200 From: Elad Ditkovski Subject: Linux 7.2 with IPv6 To: netdev@oss.sgi.com Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 154 Lines: 12 Hi, I would like to enable IPv6 on our Red Hat 7.2. Could you please suggest how should I do it. Thanks, Elad Ditkovski RADVISION elad@radvision.com From owner-netdev@oss.sgi.com Wed Mar 6 08:00:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26G0a121677 for netdev-outgoing; Wed, 6 Mar 2002 08:00:36 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26G0V921673 for ; Wed, 6 Mar 2002 08:00:31 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g26F0Iq13522; Wed, 6 Mar 2002 17:00:18 +0200 Date: Wed, 6 Mar 2002 17:00:17 +0200 (EET) From: Pekka Savola To: Elad Ditkovski cc: netdev@oss.sgi.com Subject: Re: Linux 7.2 with IPv6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 559 Lines: 25 On Wed, 6 Mar 2002, Elad Ditkovski wrote: > I would like to enable IPv6 on our Red Hat 7.2. > Could you please suggest how should I do it. Please on a Red Hat -specific list, not here. btw. browse the files in /usr/share/doc/initscripts-*/. btw.2. check out www.bieringer.de. > > > Thanks, > > > Elad Ditkovski > RADVISION > elad@radvision.com > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Wed Mar 6 09:08:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26H8ft23092 for netdev-outgoing; Wed, 6 Mar 2002 09:08:41 -0800 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26H8X923087 for ; Wed, 6 Mar 2002 09:08:33 -0800 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA26881; Wed, 6 Mar 2002 08:57:23 -0700 (MST)] Received: [from em.cig.mot.com (ripcord196.cig.mot.com [160.44.111.196]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA05230; Wed, 6 Mar 2002 09:08:16 -0700 (MST)] Received: (from piggy@localhost) by em.cig.mot.com (8.9.3/8.9.3) id KAA15638; Wed, 6 Mar 2002 10:08:15 -0600 From: "La Monte H.P. Yarroll" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 6 Mar 2002 10:08:15 -0600 (CST) To: Mauro Tortonesi Cc: Jon Grimm, , , Subject: Re: SCTP and IPv6 roadmap In-Reply-To: References: <3C4CA2E9.26253A69@austin.ibm.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15494.15799.674291.885987@theor.em.cig.mot.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3109 Lines: 70 There are some very hard problems in handling IPv6 scopes. If you want a really good PhD thesis, consider examining the problem of safe and stable load balancing across multiple asymmetric paths. E.g. what happens if SCTP sees two paths but they really share a few hops? You could end up competing with yourself for bandwidth. It's a very hard problem--that's why the Jedi Council removed load balancing from SCTP. Mauro Tortonesi writes: > On Mon, 21 Jan 2002, Jon Grimm wrote: > > > Mauro, > > > > I'm glad you ask, since it gives me a chance to put in a little plug for > > the lksctp project. > > > > No, we aren't abandoned at all. > > > > It is quite true that we've been on a base of 2.4.1 overly long. We > > are in the active process of moving to a 2.4.17 base and redoing our > > file hierarchy to better allow us to stay up with current kernels. We > > will hopefully be more nimble in the future, but our current code is > > only available as anonymous download in CVS. > > > > Overall, we'd love to get into 2.5, however realize we have a bit of > > work to focus on first. > > > > For more information, please visit the project's website at: > > http://www.sourceforge.net/projects/lksctp > > > > For more information on the SCTP protocol, see RFC 2960 at: > > http://www.ietf.org/rfc/rfc2960.txt > > thanks for your kind answer, jon. i am looking for an interesting topic > for my master thesis, and i am especially interested in next generation > networking protocols, like ipv6 and, of course, sctp. > > for my thesis, i'd really like to implement some functionality in the > linux kernel which could also be useful to the opensource community. > > unfortunately, it seems that much of ipv6 and sctp features have already > been implemented in linux, from the usagi and lksctp projects, > respectively, and there's not much left to be done - at least not so much > IMHO to do a thesis about it. > > so, if any of you has a good idea or knows an interesting networking > feature which still needs to be implemented in linux (especially some > kernel stuff) and deserves someone to write a thesis about it, please let > me know. > > thank you in advance. > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mauro@ferrara.linux.it > Ferrara Linux User Group http://www.ferrara.linux.it > Project6 - IPv6 for Linux http://project6.ferrara.linux.it > > | | > | | > ---------------------- Mailing List commands -------------------------------- > Send the following in the body of a message to Majordomo@majordomo.cig.mot.com > SUBSCRIBE TO LIST : subscribe list-name | LIST OF LISTS : lists > UNSUBSCRIBE TO LIST : unsubscribe list-name | RETRIEVE HELP : help > WHO ON ON THE LIST : who list-name | GET DESCRIPTION : info list-name > | | > Or you can use http://majordomo.cig.mot.com > ------------------------------------------------------------------------------ From owner-netdev@oss.sgi.com Wed Mar 6 13:03:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26L3pK31270 for netdev-outgoing; Wed, 6 Mar 2002 13:03:51 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26L3l931264 for ; Wed, 6 Mar 2002 13:03:48 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA16873; Wed, 6 Mar 2002 23:03:25 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200203062003.XAA16873@ms2.inr.ac.ru> Subject: Re: 'iptunnel change' can't change SIT tunnel endpoints To: xs26-dev@xs26.net Date: Wed, 6 Mar 2002 23:03:25 +0300 (MSK) Cc: pekkas@netcore.fi, netdev@oss.sgi.com In-Reply-To: <20020306142748.GM2198@pasky.ji.cz> from "Petr Baudis" at Mar 6, 2 03:27:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 505 Lines: 15 Hello! > we're having problems with 'iptunnel change' at linux 2.4.18 (non-usagi). > When we try to change endpoints of the SIT tunnel, it always fails with ENOENT. root@mops:~# ip tun add XXX mode sit remote 10.0.0.1 local 10.0.0.2 root@mops:~# ip tun ls XXX XXX: ipv6/ip remote 10.0.0.1 local 10.0.0.2 ttl inherit root@mops:~# ip tun change XXX remote 10.0.0.3 local 10.0.0.4 root@mops:~# ip tun ls XXX XXX: ipv6/ip remote 10.0.0.3 local 10.0.0.4 ttl inherit What do you see instead? Alexey From owner-netdev@oss.sgi.com Wed Mar 6 13:48:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26LmCP00497 for netdev-outgoing; Wed, 6 Mar 2002 13:48:12 -0800 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Lm4900493 for ; Wed, 6 Mar 2002 13:48:05 -0800 Received: (qmail 24250 invoked by uid 2001); 6 Mar 2002 20:48:02 -0000 Date: Wed, 6 Mar 2002 21:48:02 +0100 From: Petr Baudis To: kuznet@ms2.inr.ac.ru Cc: xs26-dev@xs26.net, pekkas@netcore.fi, netdev@oss.sgi.com Subject: Re: 'iptunnel change' can't change SIT tunnel endpoints Message-ID: <20020306204802.GV2198@pasky.ji.cz> Reply-To: xs26-dev@xs26.net References: <20020306142748.GM2198@pasky.ji.cz> <200203062003.XAA16873@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203062003.XAA16873@ms2.inr.ac.ru> User-Agent: Mutt/1.5.0i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2094 Lines: 54 Dear diary, on Wed, Mar 06, 2002 at 09:03:25PM CET, I got a letter, where kuznet@ms2.inr.ac.ru told me, that... > Hello! > > > we're having problems with 'iptunnel change' at linux 2.4.18 (non-usagi). > > When we try to change endpoints of the SIT tunnel, it always fails with ENOENT. > > root@mops:~# ip tun add XXX mode sit remote 10.0.0.1 local 10.0.0.2 > root@mops:~# ip tun ls XXX > XXX: ipv6/ip remote 10.0.0.1 local 10.0.0.2 ttl inherit > root@mops:~# ip tun change XXX remote 10.0.0.3 local 10.0.0.4 > root@mops:~# ip tun ls XXX > XXX: ipv6/ip remote 10.0.0.3 local 10.0.0.4 ttl inherit > > What do you see instead? root@machine:~# iptunnel add XXX mode sit remote 10.0.0.1 local 10.0.0.2 root@machine:~# iptunnel ls XXX XXX: ipv6/ip remote 10.0.0.1 local 10.0.0.2 ttl inherit root@machine:~# iptunnel change XXX remote 10.0.0.3 local 10.0.0.4 cannot determine tunnel mode (ipip, gre or sit) root@machine:~# iptunnel change XXX mode sit remote 10.0.0.3 local 10.0.0.4 ioctl: No such file or directory root@machine:~# iptunnel ls XXX XXX: ipv6/ip remote 10.0.0.1 local 10.0.0.2 ttl inherit We don't use 'ip' actually, but I can try.. let's install it.. (by the way, it would be nice if iproute would have entry on freshmeat.net .. i can do it if you want :).. root@machine:~# ip tun add XXX mode sit remote 10.0.0.1 local 10.0.0.2 root@machine:~# ip tun ls XXX XXX: ipv6/ip remote 10.0.0.1 local 10.0.0.2 ttl inherit root@machine:~# ip tun change XXX remote 10.0.0.3 local 10.0.0.4 root@machine:~# ip tun ls XXX XXX: ipv6/ip remote 10.0.0.3 local 10.0.0.4 ttl inherit ..strange, so it appears as a bug in iptunnel (net-tools 1.60, iptunnel 1.01). Ok, we'll switch to iproute2 instead - thanks for a hint. Best regards, -- Petr "Pasky" Baudis * elinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI hacker . "If you have acquired knowledge, what do you lack? If you lack knowledge, what have you acquired?" Lev. R. 1:6 . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From owner-netdev@oss.sgi.com Wed Mar 6 18:57:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g272v2B10230 for netdev-outgoing; Wed, 6 Mar 2002 18:57:02 -0800 Received: from web14004.mail.yahoo.com (web14004.mail.yahoo.com [216.136.175.120]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g272ux910225 for ; Wed, 6 Mar 2002 18:56:59 -0800 Message-ID: <20020307015658.10209.qmail@web14004.mail.yahoo.com> Received: from [156.153.255.243] by web14004.mail.yahoo.com via HTTP; Wed, 06 Mar 2002 17:56:58 PST Date: Wed, 6 Mar 2002 17:56:58 -0800 (PST) From: Cacophonix Subject: Re: [BETA-0.95] Sixth test release of Tigon3 driver To: davem@redhat.com Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 895 Lines: 29 [redirected to netdev] > ftp://ftp.kernel.org/pub/linux/kernel/people/davem/TIGON3/tg3-0.95.patch.gz [...] > I'm really really really really really (NO, I MEAN REALLY) interested > in performance comparisons of our 0.95 driver vs. Broadcom's stuff. I get about 550 Mb/s (tcp) with netperf on a PIII/1000, with ~40-50% CPU idle. It's much lower than the broadcom driver, which is close to line rate. No tweaks to the driver. > > But, there is one special condition if you report benchmark numbers. > If our driver is faster _AND_ you are an _Australian_ in _Australia_, > you must send Jeff and I a case of Victoria Bitter for a job well > done. :-)))))) No, it's not faster (yet), and I'm not an Australian in Australia :) --karthik __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From owner-netdev@oss.sgi.com Wed Mar 6 19:13:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g273D0e10635 for netdev-outgoing; Wed, 6 Mar 2002 19:13:00 -0800 Received: from haven.ozlabs.ibm.com (sydney1.au.ibm.com [202.135.142.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g273Ch910626 for ; Wed, 6 Mar 2002 19:12:43 -0800 Received: from wagner.rustcorp.com.au (wagner.ozlabs.ibm.com [10.61.2.77]) by haven.ozlabs.ibm.com (Postfix) with ESMTP id 8D8CD1965F; Thu, 7 Mar 2002 13:12:33 +1100 (EST) Received: from wagner.rustcorp.com.au ([127.0.0.1] helo=rustcorp.com.au) by wagner.rustcorp.com.au with esmtp (Exim 3.34 #1 (Debian)) id 16inRm-0001lJ-00; Thu, 07 Mar 2002 13:15:58 +1100 From: Rusty Russell To: Bjoern Smith Cc: netdev@oss.sgi.com Subject: Re: Serious masquerade problem In-reply-to: Your message of "Wed, 06 Mar 2002 15:34:41 BST." <3C862901.171A34C7@passad.compound.se> Date: Thu, 07 Mar 2002 13:15:58 +1100 Message-Id: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4676 Lines: 137 In message <3C862901.171A34C7@passad.compound.se> you write: > Mar 6 14:35:22 albatross kernel: Neighbour table overflow. > Mar 6 14:35:22 albatross kernel: MASQUERADE: No route: Rusty's brain > broke! > Mar 6 14:35:25 albatross last message repeated 144 times > > After a while the system gets all messed up and cannot even be > rebooted from the console. Just pulling the plug helps. This means that no route could be found for the masqueraded packets. I've never seen this before, but I think the real problem is the neighbour table overflow. CC:'d to netdev.. > This is our system: > Celeron (Coppermine)/700MHz (Dell PowerApp 110) > 256Mbyte RAM > Linux RedHat 7.1 > kernel-2.4.9-31 (not recompiled) > > > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 255.255.255.255 0.0.0.0 255.255.255.255 UH 0 0 0 > eth0 > 212.247.164.192 0.0.0.0 255.255.255.224 U 0 0 0 > eth0 > 212.247.164.224 0.0.0.0 255.255.255.224 U 0 0 0 > eth1 > 193.12.201.0 212.247.164.197 255.255.255.0 UG 0 0 0 > eth0 > 192.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth0 > 172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 > eth0 > 172.19.0.0 212.247.164.197 255.255.0.0 UG 0 0 0 > eth0 > 172.20.0.0 212.247.164.197 255.255.0.0 UG 0 0 0 > eth0 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 > lo > 0.0.0.0 212.247.164.254 0.0.0.0 UG 0 0 0 > eth1 > > > Interfaces: > eth0 Link encap:Ethernet HWaddr 00:02:B3:86:37:24 > inet addr:212.247.164.195 Bcast:212.247.164.223 = > > Mask:255.255.255.224 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:3584842 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3984789 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > Interrupt:5 Base address:0x4000 > = > > eth0:0 Link encap:Ethernet HWaddr 00:02:B3:86:37:24 > inet addr:192.0.1.1 Bcast:192.0.1.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Interrupt:5 Base address:0x4000 > = > > eth0:1 Link encap:Ethernet HWaddr 00:02:B3:86:37:24 > inet addr:172.18.0.1 Bcast:172.18.255.255 Mask:255.255.0.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Interrupt:5 Base address:0x4000 > = > > eth1 Link encap:Ethernet HWaddr 00:02:B3:86:37:25 > inet addr:212.247.164.253 Bcast:212.247.164.255 = > > Mask:255.255.255.224 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:1591438 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1192510 errors:0 dropped:0 overruns:0 carrier:0 > collisions:69390 txqueuelen:100 > Interrupt:5 Base address:0x6000 > = > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:21252 errors:0 dropped:0 overruns:0 frame:0 > TX packets:21252 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > > > # /sbin/ip rule list > 0: from all lookup local > 32765: from 172.20.0.0/16 lookup telia > 32766: from all lookup main > 32767: from all lookup 253 > > # /sbin/ip route list table telia > default via 212.247.164.196 dev eth0 > > > # /sbin/iptables -L -vn -t nat > Chain PREROUTING (policy ACCEPT 230K packets, 11M bytes) > pkts bytes target prot opt in out source = > > destination > 0 0 DROP all -- eth1 * 192.168.0.0/16 = > > 0.0.0.0/0 > 10 3536 DROP all -- eth1 * 10.0.0.0/8 = > > 0.0.0.0/0 > = > > Chain POSTROUTING (policy ACCEPT 55939 packets, 3347K bytes) > pkts bytes target prot opt in out source = > > destination > 15062 782K MASQUERADE all -- * eth1 172.18.0.0/16 = > > 0.0.0.0/0 > 1 57 MASQUERADE all -- * eth1 172.19.0.0/16 = > > 0.0.0.0/0 > 7764 399K MASQUERADE all -- * eth1 172.20.0.0/16 = > > 0.0.0.0/0 > 44041 2247K MASQUERADE all -- * eth0 172.20.0.0/16 = > > 0.0.0.0/0 > = > > Chain OUTPUT (policy ACCEPT 11777 packets, 1058K bytes) > pkts bytes target prot opt in out source = > > destination -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From owner-netdev@oss.sgi.com Thu Mar 7 03:55:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27Bt9G23022 for netdev-outgoing; Thu, 7 Mar 2002 03:55:09 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27BsH922970 for ; Thu, 7 Mar 2002 03:54:17 -0800 Received: from adsl-33-99-184.asm.bellsouth.net ([67.33.99.184] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16ivXK-0005mC-00; Thu, 07 Mar 2002 10:54:14 +0000 Message-ID: <3C8746EC.CA7B0295@mandrakesoft.com> Date: Thu, 07 Mar 2002 05:54:36 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linus Torvalds CC: "David S. Miller" , Andrew Morton , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [BK PATCHES] lotsa net driver merges Content-Type: multipart/mixed; boundary="------------B44CD004A7AFCD3665112C9E" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 17105 Lines: 486 This is a multi-part message in MIME format. --------------B44CD004A7AFCD3665112C9E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Linus, A bunch of net driver changes, few noteworthy. The interesting changes: 1) Add two helpers to PCI API, pci_set_mwi and pci_clear_mwi, for enabling and disabling Memory-Write-Invalidate transcations. This is really just a cleanup, moving code that existed in drivers/net/* for a long time into drivers/pci where it belongs. GNU PATCH ATTACHED for reference and review 2) Add new gige driver tg3 3) Add new 10/100 driver e100 4) Move tulip clone drivers into drivers/net/tulip. -No changes-, just moves the files. Eventually they will be able to share code and such nifty things... -- Jeff Garzik | Usenet Rule #2 (John Gilmore): "The Net interprets Building 1024 | censorship as damage and routes around it." MandrakeSoft | --------------B44CD004A7AFCD3665112C9E Content-Type: text/plain; charset=us-ascii; name="net-drivers-2.5.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="net-drivers-2.5.txt" Linus, Please do a bk pull http://gkernel.bkbits.net/net-drivers-2.5 to receive a whole bunch of net driver changes. ChangeSet@1.493, 2002-03-07 05:35:22-05:00, jgarzik@mandrakesoft.com Move dmfe, winbond-840, xircom_cb, xircom_tulip_cb, de2104x and de4x5 net drivers to drivers/net/tulip directory. drivers/net/de2104x.c | 2240 ------------- drivers/net/de4x5.c | 5918 ----------------------------------- drivers/net/de4x5.h | 1031 ------ drivers/net/dmfe.c | 2070 ------------ drivers/net/pcmcia/xircom_cb.c | 1245 ------- drivers/net/pcmcia/xircom_tulip_cb.c | 1744 ---------- drivers/net/winbond-840.c | 1757 ---------- Makefile | 1 drivers/net/Config.help | 83 drivers/net/Config.in | 12 drivers/net/Makefile | 13 drivers/net/pcmcia/Config.in | 5 drivers/net/pcmcia/Makefile | 5 drivers/net/tulip/Config.help | 110 drivers/net/tulip/Config.in | 27 drivers/net/tulip/Makefile | 39 drivers/net/tulip/de2104x.c | 2240 +++++++++++++ drivers/net/tulip/de4x5.c | 5918 +++++++++++++++++++++++++++++++++++ drivers/net/tulip/de4x5.h | 1031 ++++++ drivers/net/tulip/dmfe.c | 2070 ++++++++++++ drivers/net/tulip/winbond-840.c | 1757 ++++++++++ drivers/net/tulip/xircom_cb.c | 1245 +++++++ drivers/net/tulip/xircom_tulip_cb.c | 1744 ++++++++++ 23 files changed, 16178 insertions(+), 16127 deletions(-) ChangeSet@1.492, 2002-03-07 04:41:44-05:00, jgarzik@mandrakesoft.com Update starfire and tulip net drivers to use new PCI API functions pci_set_mwi and pci_clear_mwi. drivers/net/starfire.c | 15 ++++++--- drivers/net/tulip/ChangeLog | 7 ++++ drivers/net/tulip/tulip_core.c | 65 ++++++++++++++++++----------------------- 3 files changed, 48 insertions(+), 39 deletions(-) ChangeSet@1.491, 2002-03-07 04:22:59-05:00, jgarzik@mandrakesoft.com Revert to older xircom_cb net driver. This older one is far more reliable in testing, and works for all cases as near as everyone can tell. Contributor: Arjan @ RedHat drivers/net/pcmcia/xircom_cb.c | 660 +++++++++++++++-------------------------- 1 files changed, 247 insertions(+), 413 deletions(-) ChangeSet@1.490, 2002-03-07 03:48:44-05:00, jgarzik@mandrakesoft.com Merge Intel EtherExpress PRO/100 net driver "e100" from Intel, version 2.0.19, plus boolean cleanups. Bump version to 2.0.20-pre1. Contributors: Eli Kupermann @ Intel, Amir Noam @ Intel drivers/net/Config.in | 3 drivers/net/Makefile | 4 drivers/net/e100/Makefile | 16 drivers/net/e100/e100.h | 1033 +++++++++++ drivers/net/e100/e100_config.c | 596 ++++++ drivers/net/e100/e100_config.h | 206 ++ drivers/net/e100/e100_eeprom.c | 614 ++++++ drivers/net/e100/e100_main.c | 3797 +++++++++++++++++++++++++++++++++++++++++ drivers/net/e100/e100_phy.c | 1133 ++++++++++++ drivers/net/e100/e100_phy.h | 183 + drivers/net/e100/e100_proc.c | 925 +++++++++ drivers/net/e100/e100_ucode.h | 411 ++++ drivers/net/e100/e100_vendor.h | 348 +++ 13 files changed, 9268 insertions(+), 1 deletion(-) ChangeSet@1.489, 2002-03-07 03:20:03-05:00, jgarzik@mandrakesoft.com Merge new tg3 version 0.96 gigabit ethernet driver. Documentation/networking/driver.txt | 84 drivers/net/Config.help | 8 drivers/net/Config.in | 1 drivers/net/Makefile | 1 drivers/net/tg3.c | 5925 ++++++++++++++++++++++++++++++++++++ drivers/net/tg3.h | 1851 +++++++++++ drivers/pci/pci.ids | 18 include/linux/pci_ids.h | 7 8 files changed, 7895 insertions(+) ChangeSet@1.488, 2002-03-07 02:26:01-05:00, go@turbolinux.co.jp Update pcnet32 net driver with the following changes: v1.27 improved CSR/PROM address detection, lots of cleanups, new pcnet32vlb module option, HP-PARISC support, added module parameter descriptions, initial ethtool support - Helge Deller v1.27a Sun Feb 10 2002 Go Taniguchi use alloc_etherdev and register_netdev fix pci probe not increment cards_found FD auto negotiate error workaround for xSeries250 clean up and using new mii module drivers/net/pcnet32.c | 412 ++++++++++++++++++++++++-------------------------- 1 files changed, 203 insertions(+), 209 deletions(-) ChangeSet@1.487, 2002-03-07 02:18:29-05:00, davej@suse.de Add dev->last_rx = jiffies at time of raw interface packet receive, for the following net drivers: Several ham radio, several IrDA, lp4863, pcnet32, saa9730, wireless orinoco. drivers/net/hamradio/6pack.c | 1 + drivers/net/hamradio/baycom_epp.c | 1 + drivers/net/hamradio/bpqether.c | 1 + drivers/net/hamradio/hdlcdrv.c | 1 + drivers/net/hamradio/mkiss.c | 1 + drivers/net/hamradio/scc.c | 1 + drivers/net/hamradio/yam.c | 1 + drivers/net/irda/ali-ircc.c | 1 + drivers/net/irda/irda-usb.c | 1 + drivers/net/irda/nsc-ircc.c | 1 + drivers/net/irda/smc-ircc.c | 1 + drivers/net/irda/toshoboe.c | 4 +++- drivers/net/irda/vlsi_ir.c | 1 + drivers/net/irda/w83977af_ir.c | 1 + drivers/net/lp486e.c | 1 + drivers/net/pcnet32.c | 1 + drivers/net/saa9730.c | 1 + drivers/net/wireless/orinoco.c | 1 + 18 files changed, 20 insertions(+), 1 deletion(-) ChangeSet@1.486, 2002-03-07 02:08:23-05:00, p_gortmaker@yahoo.com MODULE_DESC net drivers cleanup. Idea is that if there is a valid name in MODULE_DESCRIPTION("...") then the name of the hardware/driver should not be also repeated in each MODULE_PARM_DESC("..."). MODULE_DESCRIPTION has been added to essentially all the 8390 drivers. All of the drivers changed are 8390 based, with the exception of eepro100 and 3c509. drivers/net/3c503.c | 9 +++++---- drivers/net/3c509.c | 11 ++++++----- drivers/net/ac3200.c | 9 +++++---- drivers/net/e2100.c | 11 ++++++----- drivers/net/eepro100.c | 22 +++++++++++----------- drivers/net/es3210.c | 9 +++++---- drivers/net/hp-plus.c | 7 ++++--- drivers/net/hp.c | 7 ++++--- drivers/net/lne390.c | 7 ++++--- drivers/net/ne.c | 9 +++++---- drivers/net/ne2k-pci.c | 6 +++--- drivers/net/ne3210.c | 9 +++++---- drivers/net/smc-ultra.c | 7 ++++--- drivers/net/smc-ultra32.c | 4 +++- drivers/net/wd.c | 9 +++++---- 15 files changed, 75 insertions(+), 61 deletions(-) ChangeSet@1.485, 2002-03-07 02:02:52-05:00, brownfld@irridia.com Update SysKonnect gigabit ethernet driver to support the second port on dual-port SK-9844 NICs. drivers/net/sk98lin/skge.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 42 insertions(+) ChangeSet@1.484, 2002-03-07 01:59:32-05:00, sebastian.droege@gmx.de Fix dmfe net driver build with newer binutils. drivers/net/dmfe.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) ChangeSet@1.483, 2002-03-07 01:55:49-05:00, key@austin.ibm.com lanstreamer token ring driver update: 08/15/01 - Added ioctl() functionality for debugging, changed netif_*_queue calls and other incorrectness - Kent Yoder 11/05/01 - Restructured the interrupt function, added delays, reduced the the number of TX descriptors to 1, which together can prevent the card from locking up the box - drivers/net/tokenring/lanstreamer.c | 230 ++++++++++++++++++++++++++++-------- drivers/net/tokenring/lanstreamer.h | 34 +++++ 2 files changed, 212 insertions(+), 52 deletions(-) ChangeSet@1.482, 2002-03-07 01:52:56-05:00, davej@suse.de Fix 3c505 net driver merge error: Remove duplicated ethtool ioctl handling code, fixing build. drivers/net/3c505.c | 81 ---------------------------------------------------- 1 files changed, 81 deletions(-) ChangeSet@1.481, 2002-03-06 21:47:46-05:00, jgarzik@mandrakesoft.com s/foo/DE4X5_foo/ in de4x5 net driver, to fix conflict with public namespace. drivers/net/de4x5.c | 32 ++++++++++++++++---------------- 1 files changed, 16 insertions(+), 16 deletions(-) ChangeSet@1.480, 2002-03-06 21:38:57-05:00, jgarzik@mandrakesoft.com Hand merge. include/linux/compiler.h | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) ChangeSet@1.472.1.5, 2002-03-06 21:23:59-05:00, jgarzik@mandrakesoft.com Add new architecture PCI API function helper, pdev_set_mwi(). Add new PCI API functions pci_set_mwi(), pci_clear_mwi(). Documentation/pci.txt | 7 +++ drivers/pci/pci.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/pci.h | 4 ++ 3 files changed, 109 insertions(+) ChangeSet@1.472.1.4, 2002-03-06 19:56:34-05:00, jgarzik@mandrakesoft.com Typo fix for linux/compiler.h. (a few csets later on this is auto-merged away) include/linux/compiler.h | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) ChangeSet@1.472.1.3, 2002-03-06 17:15:35-05:00, ionut@cs.columbia.edu starfire net driver updates: * Sparc64 support and fixes. * Better stats and error handling. drivers/net/Config.in | 2 - drivers/net/starfire.c | 59 ++++++++++++++++++++++++++++++++++--------------- 2 files changed, 43 insertions(+), 18 deletions(-) ChangeSet@1.472.1.2, 2002-03-06 17:08:49-05:00, jgarzik@mandrakesoft.com s/kfree/kfree_skb/ in drivers/s390/net/ctctty.c. Contributor forgotten :( drivers/s390/net/ctctty.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) ChangeSet@1.422.1.9, 2002-03-02 02:06:00-05:00, jgarzik@mandrakesoft.com Update e1000 net driver to not EXPORT_SYMBOL the standard net driver interface. drivers/net/e1000/e1000_main.c | 19 +------------------ 1 files changed, 1 insertion(+), 18 deletions(-) ChangeSet@1.422.1.8, 2002-02-28 04:46:11-05:00, jgarzik@mandrakesoft.com Update 8139cp net driver for the following: * Merge VLAN defines and support from vger, ifdef'd out until API appears in main tree. * Support RX checksumming. * Correct CP_MAX_MTU. * Clarify CP_MIN_MTU issues. drivers/net/8139cp.c | 122 ++++++++++++++++++++++++++++++++++++++++++--------- 1 files changed, 102 insertions(+), 20 deletions(-) --------------B44CD004A7AFCD3665112C9E Content-Type: text/plain; charset=us-ascii; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/Documentation/pci.txt b/Documentation/pci.txt --- a/Documentation/pci.txt Thu Mar 7 05:42:40 2002 +++ b/Documentation/pci.txt Thu Mar 7 05:42:40 2002 @@ -156,6 +156,11 @@ which enables the bus master bit in PCI_COMMAND register and also fixes the latency timer value if it's set to something bogus by the BIOS. + If you want to use the PCI Memory-Write-Invalidate transaction, +call pci_set_mwi(). This enables bit PCI_COMMAND bit for Mem-Wr-Inval +and also ensures that the cache line size register is set correctly. +Make sure to check the return value of pci_set_mwi(), not all architectures +may support Memory-Write-Invalidate. 4. How to access PCI config space ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -202,6 +207,8 @@ pci_resource_len() Returns the byte length of a PCI region pci_set_drvdata() Set private driver data pointer for a pci_dev pci_get_drvdata() Return private driver data pointer for a pci_dev +pci_set_mwi() Enable Memory-Write-Invalidate transactions. +pci_clear_mwi() Disable Memory-Write-Invalidate transactions. 7. Miscellaneous hints diff -Nru a/drivers/pci/pci.c b/drivers/pci/pci.c --- a/drivers/pci/pci.c Thu Mar 7 05:42:40 2002 +++ b/drivers/pci/pci.c Thu Mar 7 05:42:40 2002 @@ -23,6 +23,7 @@ #include /* for hotplug_path */ #include #include +#include #include #include /* isa_dma_bridge_buggy */ @@ -848,6 +849,100 @@ pcibios_set_master(dev); } +/** + * pdev_set_mwi - arch helper function for pcibios_set_mwi + * @dev: the PCI device for which MWI is enabled + * + * Helper function for implementation the arch-specific pcibios_set_mwi + * function. Originally copied from drivers/net/acenic.c. + * Copyright 1998-2001 by Jes Sorensen, . + * + * RETURNS: An appriopriate -ERRNO error value on eror, or zero for success. + */ +int +pdev_set_mwi(struct pci_dev *dev) +{ + int rc = 0; + u8 cache_size; + + /* + * Looks like this is necessary to deal with on all architectures, + * even this %$#%$# N440BX Intel based thing doesn't get it right. + * Ie. having two NICs in the machine, one will have the cache + * line set at boot time, the other will not. + */ + pci_read_config_byte(dev, PCI_CACHE_LINE_SIZE, &cache_size); + cache_size <<= 2; + if (cache_size != SMP_CACHE_BYTES) { + printk(KERN_WARNING "PCI: %s PCI cache line size set incorrectly " + "(%i bytes) by BIOS/FW, ", + dev->slot_name, cache_size); + if (cache_size > SMP_CACHE_BYTES) { + printk("expecting %i\n", SMP_CACHE_BYTES); + rc = -EINVAL; + } else { + printk("correcting to %i\n", SMP_CACHE_BYTES); + pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, + SMP_CACHE_BYTES >> 2); + } + } + + return rc; +} + +/** + * pci_set_mwi - enables memory-write-validate PCI transaction + * @dev: the PCI device for which MWI is enabled + * + * Enables the Memory-Write-Invalidate transaction in %PCI_COMMAND, + * and then calls @pcibios_set_mwi to do the needed arch specific + * operations or a generic mwi-prep function. + * + * RETURNS: An appriopriate -ERRNO error value on eror, or zero for success. + */ +int +pci_set_mwi(struct pci_dev *dev) +{ + int rc; + u16 cmd; + +#ifdef HAVE_ARCH_PCI_MWI + rc = pcibios_set_mwi(dev); +#else + rc = pdev_set_mwi(dev); +#endif + + if (rc) + return rc; + + pci_read_config_word(dev, PCI_COMMAND, &cmd); + if (! (cmd & PCI_COMMAND_INVALIDATE)) { + DBG("PCI: Enabling Mem-Wr-Inval for device %s\n", dev->slot_name); + cmd |= PCI_COMMAND_INVALIDATE; + pci_write_config_word(dev, PCI_COMMAND, cmd); + } + + return 0; +} + +/** + * pci_clear_mwi - disables Memory-Write-Invalidate for device dev + * @dev: the PCI device to disable + * + * Disables PCI Memory-Write-Invalidate transaction on the device + */ +void +pci_clear_mwi(struct pci_dev *dev) +{ + u16 cmd; + + pci_read_config_word(dev, PCI_COMMAND, &cmd); + if (cmd & PCI_COMMAND_INVALIDATE) { + cmd &= ~PCI_COMMAND_INVALIDATE; + pci_write_config_word(dev, PCI_COMMAND, cmd); + } +} + int pci_set_dma_mask(struct pci_dev *dev, u64 mask) { @@ -2002,6 +2097,9 @@ EXPORT_SYMBOL(pci_find_slot); EXPORT_SYMBOL(pci_find_subsys); EXPORT_SYMBOL(pci_set_master); +EXPORT_SYMBOL(pci_set_mwi); +EXPORT_SYMBOL(pci_clear_mwi); +EXPORT_SYMBOL(pdev_set_mwi); EXPORT_SYMBOL(pci_set_dma_mask); EXPORT_SYMBOL(pci_dac_set_dma_mask); EXPORT_SYMBOL(pci_assign_resource); diff -Nru a/include/linux/pci.h b/include/linux/pci.h --- a/include/linux/pci.h Thu Mar 7 05:42:40 2002 +++ b/include/linux/pci.h Thu Mar 7 05:42:40 2002 @@ -564,6 +564,10 @@ int pci_enable_device(struct pci_dev *dev); void pci_disable_device(struct pci_dev *dev); void pci_set_master(struct pci_dev *dev); +#define HAVE_PCI_SET_MWI +int pci_set_mwi(struct pci_dev *dev); +void pci_clear_mwi(struct pci_dev *dev); +int pdev_set_mwi(struct pci_dev *dev); int pci_set_dma_mask(struct pci_dev *dev, u64 mask); int pci_dac_set_dma_mask(struct pci_dev *dev, u64 mask); int pci_assign_resource(struct pci_dev *dev, int i); --------------B44CD004A7AFCD3665112C9E-- From owner-netdev@oss.sgi.com Thu Mar 7 10:43:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27Ihwl12605 for netdev-outgoing; Thu, 7 Mar 2002 10:43:58 -0800 Received: from angateway.acceleratednetworks.com ([12.44.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Ihq912601 for ; Thu, 7 Mar 2002 10:43:53 -0800 Received: from CALVIN.acceleratednetworks.com (calvin.acceleratednetworks.com [199.107.109.14]) by angateway.acceleratednetworks.com (8.8.8/8.8.8) with ESMTP id JAA15752; Thu, 7 Mar 2002 09:33:23 -0800 (PST) Received: by CALVIN.acceleratednetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 09:37:43 -0800 Message-ID: <8B57A2E9423E844C911DF3BC5DB06E500FA0E4@CALVIN.acceleratednetworks.com> From: Shridhar Kulkarni To: "'James Morris'" Cc: "'netdev@oss.sgi.com'" Subject: RE: NETLINK ARP DAEMON Date: Thu, 7 Mar 2002 09:36:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1042 Lines: 35 Hi, found arp helper daemon in the latest iproute2..however i am trying to compile it with the ppc82xx_gcc for our ppc platform but ARPD give me link error for func __db185_open...anybody has any ideas for this ??? -Shridhar. -----Original Message----- From: James Morris [mailto:jmorris@intercode.com.au] Sent: Monday, March 04, 2002 5:17 PM To: Shridhar Kulkarni Cc: 'netdev@oss.sgi.com' Subject: Re: NETLINK ARP DAEMON On Mon, 4 Mar 2002, Shridhar Kulkarni wrote: > Hi, > I need to implement a user-space ARP daemon for my application running on > LINUX.. I saw references all over that you have developed something like > NETLINK sockets implementation for manipulating ARP from user space. However > I did find anywhere the source code for that. Is the source code for NETLINK > ARP publicly available. I found the one for iproute2 but not for ARP.Can you > please advise ? Try a recent version of iproute2 (iproute2-2.4.7-now-ss020116-try) from ftp://ftp.inr.ac.ru/ip-routing/ - James -- James Morris From owner-netdev@oss.sgi.com Thu Mar 7 11:03:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27J3TY13188 for netdev-outgoing; Thu, 7 Mar 2002 11:03:29 -0800 Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27J1Z913165 for ; Thu, 7 Mar 2002 11:01:35 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g27I1RT23797 for ; Thu, 7 Mar 2002 13:01:27 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g27I1Ol05051 for ; Thu, 7 Mar 2002 13:01:24 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FYC2MJ2A; Thu, 7 Mar 2002 13:01:22 -0500 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQT681P6; Thu, 7 Mar 2002 13:01:24 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 4A5BF53EF for ; Thu, 7 Mar 2002 13:10:13 -0500 (EST) Message-ID: <3C87AD05.F9BC8457@nortelnetworks.com> Date: Thu, 07 Mar 2002 13:10:13 -0500 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: raw sockets, IP_HDRINCL, and fragmentation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 518 Lines: 16 Just a quick question before I try some prototyping. If I have a raw socket and set IP_HDRINCL, then send out an IP packet larger than the underlying physical layer can handle (say 2KB packets over ethernet) will the ip stack fragment the packet for me? Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Thu Mar 7 11:15:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27JFko13491 for netdev-outgoing; Thu, 7 Mar 2002 11:15:46 -0800 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27JFf913483 for ; Thu, 7 Mar 2002 11:15:41 -0800 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.52 2002/03/01 19:20:46 root Exp $) with SMTP id SAA04269 for ; Thu, 7 Mar 2002 18:15:40 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002030710144618877 ; Thu, 07 Mar 2002 10:14:46 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 10:15:39 -0800 Message-ID: From: "Hossain, Mohammad" To: "'Chris Friesen'" , netdev@oss.sgi.com Subject: RE: raw sockets, IP_HDRINCL, and fragmentation Date: Thu, 7 Mar 2002 10:15:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 815 Lines: 31 Hi, AFAIK kernel will fragment a raw packet if it exceeds the MTU of outgoing interface. Moosa -----Original Message----- From: Chris Friesen [mailto:cfriesen@nortelnetworks.com] Sent: Thursday, March 07, 2002 10:10 AM To: netdev@oss.sgi.com Subject: raw sockets, IP_HDRINCL, and fragmentation Just a quick question before I try some prototyping. If I have a raw socket and set IP_HDRINCL, then send out an IP packet larger than the underlying physical layer can handle (say 2KB packets over ethernet) will the ip stack fragment the packet for me? Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Thu Mar 7 11:16:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27JGsJ13597 for netdev-outgoing; Thu, 7 Mar 2002 11:16:54 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27JGq913594 for ; Thu, 7 Mar 2002 11:16:52 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id B50F01E952; Thu, 7 Mar 2002 19:16:46 +0100 (MET) Date: Thu, 7 Mar 2002 19:16:45 +0100 From: Andi Kleen To: Chris Friesen Cc: netdev@oss.sgi.com Subject: Re: raw sockets, IP_HDRINCL, and fragmentation Message-ID: <20020307191645.A27213@oldwotan.suse.de> References: <3C87AD05.F9BC8457@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C87AD05.F9BC8457@nortelnetworks.com>; from cfriesen@nortelnetworks.com on Thu, Mar 07, 2002 at 01:10:13PM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 376 Lines: 11 On Thu, Mar 07, 2002 at 01:10:13PM -0500, Chris Friesen wrote: > > Just a quick question before I try some prototyping. If I have a raw socket and > set IP_HDRINCL, then send out an IP packet larger than the underlying physical > layer can handle (say 2KB packets over ethernet) will the ip stack fragment the > packet for me? They are not, as documented in raw(7) -Andi From owner-netdev@oss.sgi.com Thu Mar 7 11:52:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27Jqcn14588 for netdev-outgoing; Thu, 7 Mar 2002 11:52:38 -0800 Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Joh914553 for ; Thu, 7 Mar 2002 11:50:43 -0800 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g27IoXT29214; Thu, 7 Mar 2002 13:50:33 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g27IoVL18799; Thu, 7 Mar 2002 13:50:31 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FYC2MPQT; Thu, 7 Mar 2002 13:50:28 -0500 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQT6814V; Thu, 7 Mar 2002 13:50:31 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 7E81453F4; Thu, 7 Mar 2002 13:59:19 -0500 (EST) Message-ID: <3C87B887.3757786F@nortelnetworks.com> Date: Thu, 07 Mar 2002 13:59:19 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: raw sockets, IP_HDRINCL, and fragmentation References: <3C87AD05.F9BC8457@nortelnetworks.com> <20020307191645.A27213@oldwotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 854 Lines: 25 Andi Kleen wrote: > > On Thu, Mar 07, 2002 at 01:10:13PM -0500, Chris Friesen wrote: > > > > Just a quick question before I try some prototyping. If I have a raw socket and > > set IP_HDRINCL, then send out an IP packet larger than the underlying physical > > layer can handle (say 2KB packets over ethernet) will the ip stack fragment the > > packet for me? > > They are not, as documented in raw(7) My man raw(7) says: "When the IP_HDRINCL option is set datagrams will not be fragmented and are limited to the interface MTU. This is a limitation in Linux 2.2." Does 2.4 have this same limitation? -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Thu Mar 7 11:54:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27Js9v14749 for netdev-outgoing; Thu, 7 Mar 2002 11:54:09 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Js7914746 for ; Thu, 7 Mar 2002 11:54:07 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA31718; Thu, 7 Mar 2002 21:53:50 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200203071853.VAA31718@ms2.inr.ac.ru> Subject: Re: 'iptunnel change' can't change SIT tunnel endpoints To: xs26-dev@xs26.net Date: Thu, 7 Mar 2002 21:53:50 +0300 (MSK) Cc: pekkas@netcore.fi, netdev@oss.sgi.com In-Reply-To: <20020306204802.GV2198@pasky.ji.cz> from "Petr Baudis" at Mar 6, 2 09:48:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 113 Lines: 7 Hello! > would be nice if iproute would have entry on freshmeat.net This meat is surely not fresh. :-) Alexey From owner-netdev@oss.sgi.com Thu Mar 7 12:18:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27KITm15488 for netdev-outgoing; Thu, 7 Mar 2002 12:18:29 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27KIO915484 for ; Thu, 7 Mar 2002 12:18:25 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 8B0D21E98C; Thu, 7 Mar 2002 20:18:18 +0100 (MET) Date: Thu, 7 Mar 2002 20:18:18 +0100 From: Andi Kleen To: Chris Friesen Cc: Andi Kleen , netdev@oss.sgi.com Subject: Re: raw sockets, IP_HDRINCL, and fragmentation Message-ID: <20020307201818.A8893@wotan.suse.de> References: <3C87AD05.F9BC8457@nortelnetworks.com> <20020307191645.A27213@oldwotan.suse.de> <3C87B887.3757786F@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C87B887.3757786F@nortelnetworks.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 723 Lines: 23 On Thu, Mar 07, 2002 at 01:59:19PM -0500, Chris Friesen wrote: > Andi Kleen wrote: > > > > On Thu, Mar 07, 2002 at 01:10:13PM -0500, Chris Friesen wrote: > > > > > > Just a quick question before I try some prototyping. If I have a raw socket and > > > set IP_HDRINCL, then send out an IP packet larger than the underlying physical > > > layer can handle (say 2KB packets over ethernet) will the ip stack fragment the > > > packet for me? > > > > They are not, as documented in raw(7) > > > My man raw(7) says: > > "When the IP_HDRINCL option is set datagrams will not be fragmented and are > limited to the interface MTU. This is a limitation in Linux 2.2." > > Does 2.4 have this same limitation? It has. -Andi From owner-netdev@oss.sgi.com Thu Mar 7 13:19:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27LJVr17612 for netdev-outgoing; Thu, 7 Mar 2002 13:19:31 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27LJP917609 for ; Thu, 7 Mar 2002 13:19:25 -0800 Received: from adsl-33-99-184.asm.bellsouth.net ([67.33.99.184] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16j4MF-0002Hd-00; Thu, 07 Mar 2002 20:19:24 +0000 Message-ID: <3C87CB5C.61703012@mandrakesoft.com> Date: Thu, 07 Mar 2002 15:19:40 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ben Greear CC: "David S. Miller" , Andrew Morton , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BK PATCHES] lotsa net driver merges References: <3C8746EC.CA7B0295@mandrakesoft.com> <3C879692.8010103@candelatech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1083 Lines: 37 Ben Greear wrote: > > Jeff Garzik wrote: > > > Linus, > > > > A bunch of net driver changes, few noteworthy. The interesting changes: > > > > 1) Add two helpers to PCI API, pci_set_mwi and pci_clear_mwi, for > > enabling and disabling Memory-Write-Invalidate transcations. This is > > really just a cleanup, moving code that existed in drivers/net/* for a > > long time into drivers/pci where it belongs. > > > > GNU PATCH ATTACHED for reference and review > > > > 2) Add new gige driver tg3 > > > > 3) Add new 10/100 driver e100 > > In case you are using intel's 1.8.37 driver, I can cause a kernel panic > in it by trying to reset the transceiver through MII IOCTLs.. I've > been passing email with their support, so hopefully it will be resolved > soon. Ug, did you need to quote the entire message just for this? Anyway, this is e100 version 2.0.19, with lots of changes by the Intel folks at my request. Jeff -- Jeff Garzik | Usenet Rule #2 (John Gilmore): "The Net interprets Building 1024 | censorship as damage and routes around it." MandrakeSoft | From owner-netdev@oss.sgi.com Thu Mar 7 13:49:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27Lnca18754 for netdev-outgoing; Thu, 7 Mar 2002 13:49:38 -0800 Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Llg918723 for ; Thu, 7 Mar 2002 13:47:42 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g27KlXT18148; Thu, 7 Mar 2002 15:47:33 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g27KlUl20598; Thu, 7 Mar 2002 15:47:30 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FYC2M0JQ; Thu, 7 Mar 2002 15:47:28 -0500 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQT68FDQ; Thu, 7 Mar 2002 15:47:31 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 6B83453F5; Thu, 7 Mar 2002 15:56:19 -0500 (EST) Message-ID: <3C87D3F3.315C76D5@nortelnetworks.com> Date: Thu, 07 Mar 2002 15:56:19 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: raw sockets, IP_HDRINCL, and fragmentation References: <3C87AD05.F9BC8457@nortelnetworks.com> <20020307191645.A27213@oldwotan.suse.de> <3C87B887.3757786F@nortelnetworks.com> <20020307201818.A8893@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 767 Lines: 24 Andi Kleen wrote: > > On Thu, Mar 07, 2002 at 01:59:19PM -0500, Chris Friesen wrote: > > "When the IP_HDRINCL option is set datagrams will not be fragmented and are > > limited to the interface MTU. This is a limitation in Linux 2.2." > > > > Does 2.4 have this same limitation? > > It has. Is this a technical difficulty, or just an API issue? ie, how hard would it be to hack it to add fragmentation? I'm guessing I should be looking at ip_output.c, somewhere in the vicinity of ip_build_xmit()? Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Thu Mar 7 14:29:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27MTQ420193 for netdev-outgoing; Thu, 7 Mar 2002 14:29:26 -0800 Received: from zikova.cvut.cz (zikova.cvut.cz [147.32.235.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27MTM920188 for ; Thu, 7 Mar 2002 14:29:22 -0800 Received: from vcnet.vc.cvut.cz (vcnet.vc.cvut.cz [147.32.240.61]) by zikova.cvut.cz (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id WAA21104; Thu, 7 Mar 2002 22:28:39 +0100 Received: from VCNET/SpoolDir by vcnet.vc.cvut.cz (Mercury 1.48); 7 Mar 02 22:28:39 +0100 Received: from SpoolDir by VCNET (Mercury 1.48); 7 Mar 02 22:28:25 +0100 From: "Petr Vandrovec" Organization: CC CTU Prague To: Chris Friesen Date: Thu, 7 Mar 2002 22:28:25 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: raw sockets, IP_HDRINCL, and fragmentation CC: netdev@oss.sgi.com X-mailer: Pegasus Mail v3.50 Message-ID: <13C81CDF592E@vcnet.vc.cvut.cz> Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1378 Lines: 27 On 7 Mar 02 at 15:56, Chris Friesen wrote: > > > > "When the IP_HDRINCL option is set datagrams will not be fragmented and are > > > limited to the interface MTU. This is a limitation in Linux 2.2." > > > > > > Does 2.4 have this same limitation? > > > > It has. > > Is this a technical difficulty, or just an API issue? ie, how hard would it be > to hack it to add fragmentation? I'm guessing I should be looking at > ip_output.c, somewhere in the vicinity of ip_build_xmit()? If you included header, what you would do with fragmentation? Duplicate provided header to each fragment? Should it look at provided data and inspect frag_off field to check that you set zero offset and that you did not set DF or MF? If you want fragmentation, you can set ttl/tos with IP_TOS, IP_TTL, and I cannot imagine other field you want change. BTW, should not we clear frag_off if we play with other fields in raw_getrawfrag()? Tot_len is set by raw_getrawfrag anyway, so you cannot reasonably set offset and MF in frag_off and expect target do do something meaningful. Best regards, Petr Vandrovec vandrove@vc.cvut.cz From owner-netdev@oss.sgi.com Thu Mar 7 16:10:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280ANL23809 for netdev-outgoing; Thu, 7 Mar 2002 16:10:23 -0800 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280AF923803 for ; Thu, 7 Mar 2002 16:10:15 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.52 2002/03/01 19:20:46 root Exp $) with SMTP id XAA00513 for ; Thu, 7 Mar 2002 23:10:14 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002030715132305067 for ; Thu, 07 Mar 2002 15:13:23 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 15:10:12 -0800 Message-ID: From: "Hossain, Mohammad" To: netdev@oss.sgi.com Subject: IPv6 Raw socket problem in Linux 7.2 Date: Thu, 7 Mar 2002 15:09:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2472 Lines: 76 Hello, I believe this is the best place to ask questions on ipv6 raw socket problem. Problem: I am opening am raw ipv6 socket. Then trying to send and receive data using it. But I get invalid argument(EINVAL) from both sendmsg() and recvfrom() system call when trying to send data. Why is this happening? Q: What is wrong in following code? Q: Why the error is Invalid Argument? This same code executes on Solaris IPv6 machine with little change. Q: Kernel missing some module???? How to know if my machine has raw IPv6 support or raw6 module in the kernel is installed or not. I see raw6 module is there in /proc/net dir. Pls help me out. Thanks. Arif. -----------------------oOo--------------------------Code -----------------------oOo-------------------------- int enable=1; struct sockaddr_in6 srcAddr6; size=sizeof(sockaddr_in6); ....... sd=socket(AF_INET6, SOCK_RAW, IPPROTO_RAW); /*ipv6 raw socket*/ /* set socket options */ ioctl(sd,(S32)FIONBIO, &enable); /* make socket NonBlocking */ setsockopt(sd, level, SO_BSDCOMPAT,&enable, sizeof(enable)); setsockopt(sd, level, SO_REUSEADDR,(char*)&enable,sizeof(enable)); /* binding */ cmMemset((U8*)&srcAddr6, 0, sizeof(srcAddr6)); srcAddr6.sin6_family = AF_INET6; srcAddr6.sin6_port = CM_INET_HTON_U16(port); COPY_IPV6ADDR(&srcAddr6.sin6_addr,&in6addr_loopback); /*loopback used*/ sizeOfAddr = sizeof(struct sockaddr_in6); sockAddrPtr = (sockAddr *)&srcAddr6; bind(sd, sockAddrPtr, sizeOfAddr); getsockname(sd, &lclSockAddr, (int*)&size); sending data: struct sockaddr_in6 remAddr6; int sizeOfAddr; struct msghdr msg; char buffer [1][100]; struct iovec io[1]; remAddr6.sin6_family = AF_INET6; remAddr6.sin6_port = CM_INET_HTON_U16(12447); COPY_IPV6ADDR(&remAddr6.sin6_addr, &in6addr_loopback); /* macro */ sizeOfAddr = sizeof(remAddr6); cmMemset(&msg, 0, sizeof(msg)); /*fill up msg with all 0*/ msg.msg_name = (void*)&remAddr6; msg.msg_namelen = sizeOfAddr; io[0].iov_base = buffer[0]; sprintf(buffer[0]," This is a test\n"); io[0].iov_len = strlen(buffer[0]); msg.msg_iov = io; msg.msg_iovlen = 1; msg.msg_control = NULL; msg.msg_controllen = 0; msg.msg_flags = 0; ret = sendmsg(sd, &msg, 0); ===> returns (-1):EINVAL or recvfrom(.......) ===> returns (-1): EINVAL too. From owner-netdev@oss.sgi.com Thu Mar 7 17:01:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28113X01977 for netdev-outgoing; Thu, 7 Mar 2002 17:01:03 -0800 Received: from courage.cs.stevens-tech.edu (IDENT:postfix@courage.cs.stevens-tech.edu [155.246.89.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2810x901961 for ; Thu, 7 Mar 2002 17:00:59 -0800 Received: by courage.cs.stevens-tech.edu (Postfix, from userid 4041) id 59C91913E4; Thu, 7 Mar 2002 17:39:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by courage.cs.stevens-tech.edu (Postfix) with ESMTP id 3B9CC913E3; Thu, 7 Mar 2002 17:39:48 -0500 (EST) Newsgroups: comp.os.linux.development.system Date: Thu, 7 Mar 2002 17:39:45 -0500 (EST) From: Marek Zawadzki Cc: Subject: Accept -- still confused. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1125 Lines: 28 Hello, I've been trying to implement queuing and 'accept' in my protocol for few weeks. The way 'accept' should work is still not clear for me: We have a socket s and we do the following in the server: 1. listen(s) -- thus s->sk_state = TCP_LISTEN. 2. accept(s) -- put a process into sleep. ... 3. receiving function gets an 'init' packet and looks for a socket which matches packet's destination. The lookup returns s (!). 4. I put s on a queue (sk->tp_pinfo.af_tcp.accept_queue) and wake up the process (why to put s itself on it's own queue?). 5. accept resumes, grabs first socket from the queue (s) and changes its' state to TCP_ESTABLISHED and returns it to inet_accpet. (but this is the same socket we've been listening on:( ). 6. inet_accept grafts s into a new socket(ok), but s is now in TCP_ESTABLISHED state, instead of TCP_LISTEN, which ruins next connection. How to keep the listening state and return the valid socket to inet_accept, without messing with inet_accept itself? My problem is the socket I am listening on and to which the 'init' packet is destinated are the same. Thanks for anything. -marek From owner-netdev@oss.sgi.com Thu Mar 7 17:17:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g281HoY02586 for netdev-outgoing; Thu, 7 Mar 2002 17:17:50 -0800 Received: from colin.pp.htv.fi (qmailr@colin.pp.htv.fi [212.90.94.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g281Hf902579 for ; Thu, 7 Mar 2002 17:17:41 -0800 Received: (qmail 5284 invoked by uid 1000); 8 Mar 2002 00:17:38 -0000 Date: Fri, 8 Mar 2002 02:17:38 +0200 From: Heikki Kallasjoki To: "Hossain, Mohammad" Cc: netdev@oss.sgi.com Subject: Re: IPv6 Raw socket problem in Linux 7.2 Message-ID: <20020308021738.A4167@ubiquitous.eu.org> Mail-Followup-To: "Hossain, Mohammad" , netdev@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from m_hossain@trillium.com on Thu, Mar 07, 2002 at 03:09:58PM -0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2599 Lines: 67 On Thu, Mar 07, 2002 at 03:09:58PM -0800, Hossain, Mohammad wrote: > Problem: > I am opening am raw ipv6 socket. Then trying to send and receive data > using it. But I get invalid argument(EINVAL) from both sendmsg() > and recvfrom() system call when trying to send data. Why is this happening? Not sure, but trying to answer the first question.. > Q: What is wrong in following code? By simply looking, can't spot any errors. The following code runs without any error messages on my system, you might want to check if it works there - if it doesn't, the problem is most probably in your system setup, not in the code: --- test.c --- #include #include #include #include #include int main(void) { struct sockaddr_in6 addr6; int size, sd, enable = 1, i; struct msghdr msg; struct iovec io; char buf[100]; sd = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW); if(sd == -1) { perror("socket()"); exit(1); } if(ioctl(sd, FIONBIO, &enable) == -1) { perror("ioctl()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_BSDCOMPAT, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } memset(&addr6, 0, sizeof(addr6)); size = sizeof(struct sockaddr_in6); addr6.sin6_family = AF_INET6; addr6.sin6_port = htons(42); memcpy(&addr6.sin6_addr, &in6addr_loopback, sizeof(struct in6_addr)); if(bind(sd, (struct sockaddr *)&addr6, size) == -1) { perror("bind()"); exit(1); } io.iov_base = buf; io.iov_len = 100; msg.msg_name = &addr6; msg.msg_namelen = sizeof(struct sockaddr_in6); msg.msg_iov = &io; msg.msg_iovlen = 1; msg.msg_control = NULL; msg.msg_controllen = 0; msg.msg_flags = 0; i = sendmsg(sd, &msg, 0); if(i == -1) { perror("sendmsg()"); exit(1); } exit(0); --- test.c --- It should be essentially equivalent to what you posted. > Q: Kernel missing some module???? > How to know if my machine has raw IPv6 support or raw6 module in > the kernel is installed or not. I see > raw6 module is there in /proc/net dir. /proc/net/raw6 should be a list of opened raw sockets, AFAIK. Kernel version numbers (output of 'uname -a') might be helpful, my system is "Linux 2.4.18 #21 Tue Feb 26 13:02:07 EET 2002 i586 unknown" and raw v6 sockets seem to work well on this. -- >#v1&#:<-1<-1\0\_.@ "You cannot escape from window 0!" >2-!#v_:2\^fibre^-< fizban at iki dot fi ^:_ >$1>\#+:#$!_1^ PGP key fp 657AF64968F12E6ECBE5F90E421C1FDF9EC09E94 From owner-netdev@oss.sgi.com Thu Mar 7 17:34:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g281YOw03130 for netdev-outgoing; Thu, 7 Mar 2002 17:34:24 -0800 Received: from r2d2.aussec.com (IDENT:kqeOeFDOCOMs8U+UGBjAy6rbc1tr/Ubl@r2d2.aussec.com [202.7.95.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g281YG903125 for ; Thu, 7 Mar 2002 17:34:18 -0800 Received: from home.aussec.com (home.aussec.com [192.168.0.10]) by r2d2.aussec.com (8.12.2/8.12.2) with ESMTP id g280YDrd023135 for ; Fri, 8 Mar 2002 11:34:13 +1100 Date: Fri, 8 Mar 2002 11:30:09 +1100 (EST) From: tom burkart To: netdev@oss.sgi.com Subject: Potential issue with IP network stack Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1490 Lines: 41 Description of problem: Scenario1: ADSL connection --- CISCO ADSL router --- Linux server --- private network Scenario2: ADSL connection --- Alcatel modem --- Linux server/firewall --- private network Scenario3: ADSL connection --- Alcatel modem --- Linux firewall --- Linux server --- private network Scenario4: ISDN connection --- Linux firewall --- Linux server --- Linux firewall --- private network Problem the Linux server in (1) and (2) will not connect properly to certain mail servers (usually telcos). Also "telnet mailhost5.wcom.com.hk 25" does not work (it says: "Connecting to ", but doesn't - tcpdump reveals that it sends packets but does not receive any). The funny part is that in (1) it works properly from both, the CISCO router AND from the internal network. With (2) it works properly from the internal network. (3) and (4) work fine under all circumstances. (1) and (2) use 2.4.17, 2.4.18 (3) uses 2.4.17 on the firewall and 2.2.? on the inside (4) uses 2.4.17 on the firewalls and 2.4.? on the server It appears that as long as the mail server has a Linux box forwarding packets for it then it will work... It also appears that all of the servers it has problems with do run a M$ OS - which I can't fix ;-) Is there anything else I can try, to narrow down the area to look at? Is there something obvious I might be doing wrong? tom. Consultant AUSSEC Phone: 61 4 1768 2202 339 Blaxland Rd., Ryde NSW 2112 Email: tom@aussec.com From owner-netdev@oss.sgi.com Thu Mar 7 20:36:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g284aFL07540 for netdev-outgoing; Thu, 7 Mar 2002 20:36:15 -0800 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g284Zr907529 for ; Thu, 7 Mar 2002 20:35:53 -0800 Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.52 2002/03/01 19:20:46 root Exp $) with SMTP id DAA27005 for ; Fri, 8 Mar 2002 03:35:47 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002030719413319658 ; Thu, 07 Mar 2002 19:41:33 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 19:35:46 -0800 Message-ID: From: "Hossain, Mohammad" To: "'Heikki Kallasjoki'" , "Hossain, Mohammad" Cc: netdev@oss.sgi.com Subject: RE: IPv6 Raw socket problem in Linux 7.2 Date: Thu, 7 Mar 2002 19:35:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g284Zr907530 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 6142 Lines: 201 Hello, Thanks for reading and you valuable time. I appreciate. Would you pls check if the code below works in your Linux IPv6 machine? This code opens an IPv6 raw socket and call select to read raw data from this socket. I have spent many hours to find out why I am getting 0 from select in my machine. I am getting EAGAIN due to select timeout on my machine. Is my code wrong OR Linux IPv6 setting on my machine is wrong????? Have nice time. Thanks Arif -----------------------test.c----------------------------- #include #include #include #include #include #include /* for select() */ #include #include int main(void) { /* variables for opening socket & sending data */  struct sockaddr_in6 addr6; int size, sd, enable = 1, i; struct msghdr msg; struct iovec io; char buf[15]; /* variables for receiving data */ struct sockaddr_in6 remSockAddr6; struct msghdr msgRecv; struct iovec ioRecv; char bufRecv[100]; int recvLen = 0; /* variables for select() */ fd_set rFdSet; struct timeval selTime; int num; sd = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW); printf("sd is %d\n",sd); if(sd == -1) { perror("socket()"); exit(1); } if(ioctl(sd, FIONBIO, &enable) == -1) { perror("ioctl()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_BSDCOMPAT, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } memset(&addr6, 0, sizeof(addr6)); size = sizeof(struct sockaddr_in6); addr6.sin6_family = AF_INET6; addr6.sin6_port = htons(42); memcpy(&addr6.sin6_addr, &in6addr_loopback, sizeof(struct in6_addr)); if(bind(sd, (struct sockaddr *)&addr6, size) == -1) { perror("bind()"); exit(1); } sprintf(buf, "This is a test"); io.iov_base = buf; io.iov_len = 15; msg.msg_name = &addr6; msg.msg_namelen = sizeof(struct sockaddr_in6); msg.msg_iov = &io; msg.msg_iovlen = 1; msg.msg_control = NULL; msg.msg_controllen = 0; msg.msg_flags = 0; i = sendmsg(sd, &msg, 0); printf("%d bytes sent\n", i); if(i == -1) { perror("sendmsg()"); exit(1); } /* receiving Raw IPv6 Data */ FD_ZERO(&rFdSet); FD_SET(sd, &rFdSet); selTime.tv_sec = 20; /* select will wait 20 sec for data */ selTime.tv_usec = 0; num = select(sd+1, &rFdSet, NULL, NULL, &selTime); if(num <= 0) printf("No data arrived as no socket!\n"); else if FD_ISSET(sd, &rFdSet) {  memset(&remSockAddr6, 0, sizeof(remSockAddr6)); memset(&msgRecv, 0, sizeof(msgRecv)); ioRecv.iov_base = bufRecv; ioRecv.iov_len = 0; msgRecv.msg_name = (void *)&remSockAddr6; msgRecv.msg_namelen = sizeof(remSockAddr6); msgRecv.msg_control = NULL; msgRecv.msg_controllen = 0; msgRecv.msg_iov = &ioRecv; msgRecv.msg_iovlen = 1;  msgRecv.msg_flags = 0; recvLen = recvmsg(sd, &msgRecv, 0); printf("error no: %d\n",errno); if(errno == EINVAL) printf("Invalid Argument\n"); printf("Data recvd %d Bytes\n",recvLen); } exit(0); } -----Original Message----- From: Heikki Kallasjoki [mailto:fizban@iki.fi] Sent: Thursday, March 07, 2002 4:18 PM To: Hossain, Mohammad Cc: netdev@oss.sgi.com Subject: Re: IPv6 Raw socket problem in Linux 7.2 On Thu, Mar 07, 2002 at 03:09:58PM -0800, Hossain, Mohammad wrote: > Problem: > I am opening am raw ipv6 socket. Then trying to send and receive data > using it. But I get invalid argument(EINVAL) from both sendmsg() > and recvfrom() system call when trying to send data. Why is this happening? Not sure, but trying to answer the first question.. > Q: What is wrong in following code? By simply looking, can't spot any errors. The following code runs without any error messages on my system, you might want to check if it works there - if it doesn't, the problem is most probably in your system setup, not in the code: --- test.c --- #include #include #include #include #include int main(void) { struct sockaddr_in6 addr6; int size, sd, enable = 1, i; struct msghdr msg; struct iovec io; char buf[100]; sd = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW); if(sd == -1) { perror("socket()"); exit(1); } if(ioctl(sd, FIONBIO, &enable) == -1) { perror("ioctl()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_BSDCOMPAT, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } memset(&addr6, 0, sizeof(addr6)); size = sizeof(struct sockaddr_in6); addr6.sin6_family = AF_INET6; addr6.sin6_port = htons(42); memcpy(&addr6.sin6_addr, &in6addr_loopback, sizeof(struct in6_addr)); if(bind(sd, (struct sockaddr *)&addr6, size) == -1) { perror("bind()"); exit(1); } io.iov_base = buf; io.iov_len = 100; msg.msg_name = &addr6; msg.msg_namelen = sizeof(struct sockaddr_in6); msg.msg_iov = &io; msg.msg_iovlen = 1; msg.msg_control = NULL; msg.msg_controllen = 0; msg.msg_flags = 0; i = sendmsg(sd, &msg, 0); if(i == -1) { perror("sendmsg()"); exit(1); } exit(0); --- test.c --- It should be essentially equivalent to what you posted. > Q: Kernel missing some module???? > How to know if my machine has raw IPv6 support or raw6 module in > the kernel is installed or not. I see > raw6 module is there in /proc/net dir. /proc/net/raw6 should be a list of opened raw sockets, AFAIK. Kernel version numbers (output of 'uname -a') might be helpful, my system is "Linux 2.4.18 #21 Tue Feb 26 13:02:07 EET 2002 i586 unknown" and raw v6 sockets seem to work well on this. -- >#v1&#:<-1<-1\0\_.@ "You cannot escape from window 0!" >2-!#v_:2\^fibre^-< fizban at iki dot fi ^:_ >$1>\#+:#$!_1^ PGP key fp 657AF64968F12E6ECBE5F90E421C1FDF9EC09E94 From owner-netdev@oss.sgi.com Fri Mar 8 00:49:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g288nOt13233 for netdev-outgoing; Fri, 8 Mar 2002 00:49:24 -0800 Received: from colin.pp.htv.fi (qmailr@colin.pp.htv.fi [212.90.94.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g288nJ913229 for ; Fri, 8 Mar 2002 00:49:19 -0800 Received: (qmail 20244 invoked by uid 1000); 8 Mar 2002 07:49:18 -0000 Date: Fri, 8 Mar 2002 09:49:18 +0200 From: "'Heikki Kallasjoki'" To: "Hossain, Mohammad" Cc: netdev@oss.sgi.com Subject: Re: IPv6 Raw socket problem in Linux 7.2 Message-ID: <20020308094918.A19065@ubiquitous.eu.org> Mail-Followup-To: "Hossain, Mohammad" , netdev@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from m_hossain@trillium.com on Thu, Mar 07, 2002 at 07:35:16PM -0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1247 Lines: 33 On Thu, Mar 07, 2002 at 07:35:16PM -0800, Hossain, Mohammad wrote: > Would you pls check if the code below works in your Linux IPv6 machine? Well, it "works": no errors, but no data from the socket either. Not sure whether this applies to IPv6 too, but I'll quote the raw(7) man page for ipv4 raw sockets: --- raw_socket = socket(PF_INET, SOCK_RAW, int protocol); All packets or errors matching the protocol number specified for the raw socket are passed to this socket. For a list of the allowed protocols see RFC1700 assigned numbers and getprotobyname(3). A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and receives all IP protocols. Sending is not allowed. .. An IPPROTO_RAW socket is send only. If you really want to receive all IP packets use a packet(7) socket with the ETH_P_IP protocol. Note that packet sockets don't reassemble IP fragments, unlike raw sockets. --- Which, to me, seems a bit contradictory. Anyway, that might be the cause of your problems - you might want to try specifying the protocol in your call to socket, if possible. -- >#v1&#:<-1<-1\0\_.@ "You cannot escape from window 0!" >2-!#v_:2\^fibre^-< fizban at iki dot fi ^:_ >$1>\#+:#$!_1^ PGP key fp 657AF64968F12E6ECBE5F90E421C1FDF9EC09E94 From owner-netdev@oss.sgi.com Fri Mar 8 01:17:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g289HGX19728 for netdev-outgoing; Fri, 8 Mar 2002 01:17:16 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g289HC919725 for ; Fri, 8 Mar 2002 01:17:12 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A788A1E146; Fri, 8 Mar 2002 09:17:06 +0100 (MET) Date: Fri, 8 Mar 2002 09:17:06 +0100 From: Andi Kleen To: Chris Friesen Cc: Andi Kleen , netdev@oss.sgi.com Subject: Re: raw sockets, IP_HDRINCL, and fragmentation Message-ID: <20020308091706.A17147@wotan.suse.de> References: <3C87AD05.F9BC8457@nortelnetworks.com> <20020307191645.A27213@oldwotan.suse.de> <3C87B887.3757786F@nortelnetworks.com> <20020307201818.A8893@wotan.suse.de> <3C87D3F3.315C76D5@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C87D3F3.315C76D5@nortelnetworks.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1053 Lines: 25 On Thu, Mar 07, 2002 at 03:56:19PM -0500, Chris Friesen wrote: > Andi Kleen wrote: > > > > On Thu, Mar 07, 2002 at 01:59:19PM -0500, Chris Friesen wrote: > > > > "When the IP_HDRINCL option is set datagrams will not be fragmented and are > > > limited to the interface MTU. This is a limitation in Linux 2.2." > > > > > > Does 2.4 have this same limitation? > > > > It has. > > Is this a technical difficulty, or just an API issue? ie, how hard would it be > to hack it to add fragmentation? I'm guessing I should be looking at > ip_output.c, somewhere in the vicinity of ip_build_xmit()? It is not clear if it makes sense at all. Fragmenting would require changing the IP header you supplied. Do you expect that? It is probably better to never change the IP header with IP_HDRINCL. In fact on Linux you should not really ever need to use IP_HDRINCL. Nearly everything that can be usefully changed on an IP header (ttl,tos,options,addresses etc.) can be changed with other socket options too and these are compatible with fragmenting. -Andi From owner-netdev@oss.sgi.com Fri Mar 8 01:23:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g289NhN20336 for netdev-outgoing; Fri, 8 Mar 2002 01:23:43 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g289Nd920333 for ; Fri, 8 Mar 2002 01:23:40 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 0E7A31E146; Fri, 8 Mar 2002 09:23:34 +0100 (MET) Date: Fri, 8 Mar 2002 09:23:26 +0100 From: Andi Kleen To: tom burkart Cc: netdev@oss.sgi.com Subject: Re: Potential issue with IP network stack Message-ID: <20020308092326.A17822@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1013 Lines: 22 > Problem the Linux server in (1) and (2) will not connect properly to > certain mail servers (usually telcos). Also "telnet mailhost5.wcom.com.hk > 25" does not work (it says: "Connecting to ", > but doesn't - tcpdump reveals that it sends packets but does not receive > any). The funny part is that in (1) it works properly from both, the > CISCO router AND from the internal network. With (2) it works properly > from the internal network. > (3) and (4) work fine under all circumstances. The other side is likely pmtu blackholed and blocking all ICMPs (misconfigured firewall) Set a mss of 1440 on the default route and flush the routing cache afterwards (ip route replace default .... advmss 1440 ; ip route flush) Another possibility is ECN, make sure it is turned off. Would be again a broken firewall on the other side. echo 0 > /proc/sys/net/ipv4/tcp_ecn -Andi P.S.: netdev is for network code development. your question would have been more appropiate on linux-net. From owner-netdev@oss.sgi.com Fri Mar 8 06:11:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28EBfN28967 for netdev-outgoing; Fri, 8 Mar 2002 06:11:41 -0800 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28EBY928964 for ; Fri, 8 Mar 2002 06:11:35 -0800 Received: (qmail 13090 invoked by uid 2001); 8 Mar 2002 13:11:31 -0000 Date: Fri, 8 Mar 2002 14:11:31 +0100 From: Petr Baudis To: pekkas@netcore.fi, netdev@oss.sgi.com Cc: kuznet@ms2.inr.ac.ru, xs26-dev@xs26.net Subject: Re: addrconf.c - possible bug Message-ID: <20020308131131.GR2198@pasky.ji.cz> Reply-To: xs26-dev@xs26.net References: <20020308134828.A214@ipv6.isternet.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020308134828.A214@ipv6.isternet.sk> User-Agent: Mutt/1.5.0i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1291 Lines: 39 Dear diary, on Fri, Mar 08, 2002 at 01:48:28PM CET, I got a letter, where Jan Oravec told me, that... > Hello, > > In function addrconf_rs_timer, the code increases ifp->probes, but it's > never reset (except DAD). That is probably causing that neighbor > solicitation doesn't work correctly and in order to use IGP routing daemons > (e.g. OSPFv3 included in 'zebra' package), it must work, otherwise OSPF > daemons are not able to connect, because their packets are not delivered > because router doesn't receive neighbor solicitation response. > > Best Regards, > > -- > Jan Oravec > project coordinator > XS26 - 'Access to IPv6' > jan.oravec@xs26.net In order to clarify this even a bit more - it will try to send the neigh sol three times (or whatever arbitrary number is set for the interface), and if it will fail, it will never try to resend it once more. Tested on linux-2.4.18 (non-usagi). Kind regards, -- Petr "Pasky" Baudis * elinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI hacker . "If you have acquired knowledge, what do you lack? If you lack knowledge, what have you acquired?" Lev. R. 1:6 . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From owner-netdev@oss.sgi.com Fri Mar 8 07:33:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28FXHS31923 for netdev-outgoing; Fri, 8 Mar 2002 07:33:17 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28FX8931919 for ; Fri, 8 Mar 2002 07:33:08 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g28EWtx08771; Fri, 8 Mar 2002 16:32:55 +0200 Date: Fri, 8 Mar 2002 16:32:55 +0200 (EET) From: Pekka Savola To: xs26-dev@xs26.net cc: netdev@oss.sgi.com, Subject: Re: addrconf.c - possible bug In-Reply-To: <20020308131131.GR2198@pasky.ji.cz> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-338029647-1015597975=:8730" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2732 Lines: 71 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1589707168-338029647-1015597975=:8730 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, A problem seems to be is that ifp->probes has been overloaded for both RS's and NS's (rtr solicits and DAD basically), and they're used differently: DAD starts from number X (X>0) decrementing it and RS start from (assumed to be zero), incrementing it. So there _appears_ to be a possible race there. I'm not not 100% confortable with my analysis though, so I'm sure Alexey will correct me if/when I'm wrong. If this is the case, perhaps the attached patch would do.. disclaimer: untested. On Fri, 8 Mar 2002, Petr Baudis wrote: > Dear diary, on Fri, Mar 08, 2002 at 01:48:28PM CET, I got a letter, > where Jan Oravec told me, that... > > Hello, > > > > In function addrconf_rs_timer, the code increases ifp->probes, but it's > > never reset (except DAD). That is probably causing that neighbor > > solicitation doesn't work correctly and in order to use IGP routing daemons > > (e.g. OSPFv3 included in 'zebra' package), it must work, otherwise OSPF > > daemons are not able to connect, because their packets are not delivered > > because router doesn't receive neighbor solicitation response. > > > > Best Regards, > > > > -- > > Jan Oravec > > project coordinator > > XS26 - 'Access to IPv6' > > jan.oravec@xs26.net > > In order to clarify this even a bit more - it will try to send the neigh sol > three times (or whatever arbitrary number is set for the interface), and if it > will fail, it will never try to resend it once more. > > Tested on linux-2.4.18 (non-usagi). > > Kind regards, > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords --1589707168-338029647-1015597975=:8730 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ipv6-ns_prbes.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ipv6-ns_prbes.diff" LS0tIGFkZHJjb25mLmMJRnJpIFNlcCAgNyAyMTowMToyMSAyMDAxDQorKysg YWRkcmNvbmYuYy5uZXcJRnJpIE1hciAgOCAxNjoyNjo1MiAyMDAyDQpAQCAt MTM5Nyw2ICsxMzk3LDcgQEANCiAJfQ0KIA0KIAlzcGluX2xvY2soJmlmcC0+ bG9jayk7DQorCWlmcC0+cHJvYmVzID0gMDsNCiAJaWYgKGlmcC0+cHJvYmVz KysgPCBpZnAtPmlkZXYtPmNuZi5ydHJfc29saWNpdHMpIHsNCiAJCXN0cnVj dCBpbjZfYWRkciBhbGxfcm91dGVyczsNCiANCg== --1589707168-338029647-1015597975=:8730-- From owner-netdev@oss.sgi.com Fri Mar 8 20:16:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g294G4118914 for netdev-outgoing; Fri, 8 Mar 2002 20:16:04 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g294G2918911 for ; Fri, 8 Mar 2002 20:16:02 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA31132; Fri, 8 Mar 2002 19:13:16 -0800 Date: Fri, 08 Mar 2002 19:13:15 -0800 (PST) Message-Id: <20020308.191315.21951232.davem@redhat.com> To: cacophonix@yahoo.com Cc: netdev@oss.sgi.com Subject: Re: [BETA-0.95] Sixth test release of Tigon3 driver From: "David S. Miller" In-Reply-To: <20020307015658.10209.qmail@web14004.mail.yahoo.com> References: <20020307015658.10209.qmail@web14004.mail.yahoo.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 348 Lines: 9 From: Cacophonix Date: Wed, 6 Mar 2002 17:56:58 -0800 (PST) I get about 550 Mb/s (tcp) with netperf on a PIII/1000, with ~40-50% CPU idle. It's much lower than the broadcom driver, which is close to line rate. No tweaks to the driver. Please retry with 0.96 which is substantially faster on x86 hardware. From owner-netdev@oss.sgi.com Fri Mar 8 21:15:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g295Fcj19885 for netdev-outgoing; Fri, 8 Mar 2002 21:15:38 -0800 Received: from web14001.mail.yahoo.com (web14001.mail.yahoo.com [216.136.175.92]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g295FZ919881 for ; Fri, 8 Mar 2002 21:15:35 -0800 Message-ID: <20020309041535.50626.qmail@web14001.mail.yahoo.com> Received: from [156.153.255.236] by web14001.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 20:15:35 PST Date: Fri, 8 Mar 2002 20:15:35 -0800 (PST) From: Cacophonix Subject: Re: [BETA-0.95] Sixth test release of Tigon3 driver To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <20020308.191315.21951232.davem@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 634 Lines: 21 --- "David S. Miller" wrote: > From: Cacophonix > Date: Wed, 6 Mar 2002 17:56:58 -0800 (PST) > > I get about 550 Mb/s (tcp) with netperf on a PIII/1000, with ~40-50% CPU idle. > It's much lower than the broadcom driver, which is close to line rate. > No tweaks to the driver. > > Please retry with 0.96 which is substantially faster on x86 > hardware. yes indeed, this nudges throughput to ~900-910 Mb/s, at 100% cpu. :-) __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From owner-netdev@oss.sgi.com Sat Mar 9 01:38:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g299c6d24425 for netdev-outgoing; Sat, 9 Mar 2002 01:38:06 -0800 Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g299c1924420 for ; Sat, 9 Mar 2002 01:38:01 -0800 Received: from dd.qc.ca ([66.130.115.91]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id GSP6NB04.06N for ; Sat, 9 Mar 2002 03:37:59 -0500 Message-ID: <3C89C85D.9070505@dd.qc.ca> Date: Sat, 09 Mar 2002 03:31:25 -0500 From: Dominic Duval User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: ipv4.o module Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1168 Lines: 31 Hi everyone, I recently spent some time working on the "modularization" of the ipv4 stack. More precisely, this allows anyone to boot the kernel without any ipv4 support (thus saving about 200k of RAM) and load a module implementing the TCP/IP stack latter on. The code is now at a stage where the ipv4.o module can be inserted and removed at will, and it's actually quite stable (although it still needs to be tested more heavily) . I know some people have shown some interest for this feature in the past, so your feedback is appreaciated. The patch is available for version 2.4.17 of the kernel, and can be downloaded at the following location: http://www-edu.gel.usherb.ca/duvd01/linux/diff-2.4.17-ipv4-0.11 Before anyone asks why ipv4 modularization is necesary: we are currently making some heavy modifications to the TCP/IP stack for another project, and modularizing the whole thing was the easiest way to optimize development time, since the old "patch, compile, reboot, test" cycle is now unnecessary with this patch. Again, ideas/suggestions/comments are welcomed. -- Dominic Duval Étudiant, Génie Informatique Université de Sherbrooke From owner-netdev@oss.sgi.com Sat Mar 9 07:41:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29FfoW00537 for netdev-outgoing; Sat, 9 Mar 2002 07:41:50 -0800 Received: from zmailer.org ([195.163.186.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29Ffg900531 for ; Sat, 9 Mar 2002 07:41:43 -0800 Received: (mea@mea-ext) by mail.zmailer.org id convert rfc822-to-quoted-printable; Sat, 9 Mar 2002 16:41:31 +0200 Date: Sat, 9 Mar 2002 16:41:31 +0200 From: Matti Aarnio To: Dominic Duval Cc: netdev@oss.sgi.com Subject: Re: ipv4.o module Message-ID: <20020309164131.D10704@mea-ext.zmailer.org> References: <3C89C85D.9070505@dd.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: QUOTED-PRINTABLE In-Reply-To: <3C89C85D.9070505@dd.qc.ca>; from dd@dd.qc.ca on Sat, Mar 09, 2002 at 03:31:25AM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1669 Lines: 50 On Sat, Mar 09, 2002 at 03:31:25AM -0500, Dominic Duval wrote: > Hi everyone, >=20 > I recently spent some time working on the "modularization" of the ipv= 4=20 > stack. More precisely, this allows anyone to boot the kernel without = any=20 > ipv4 support (thus saving about 200k of RAM) and load a module=20 > implementing the TCP/IP stack latter on. Excellent. I had plan to do that latter this spring, but like always, there are parallel developments. One of my goals is to rip the TCP and UDP into separate submodules, so that we can in fact load in TCP, UDP and preferred IP (4 and/or 6) layers. You don't (yet) have 2.5.* diffs ? /Matti Aarnio > The code is now at a stage where the ipv4.o module can be inserted an= d=20 > removed at will, and it's actually quite stable (although it still ne= eds=20 > to be tested more heavily) . I know some people have shown some inter= est=20 > for this feature in the past, so your feedback is appreaciated. The=20 > patch is available for version 2.4.17 of the kernel, and can be=20 > downloaded at the following location: >=20 > http://www-edu.gel.usherb.ca/duvd01/linux/diff-2.4.17-ipv4-0.11 >=20 > Before anyone asks why ipv4 modularization is necesary: we are curren= tly=20 > making some heavy modifications to the TCP/IP stack for another proje= ct,=20 > and modularizing the whole thing was the easiest way to optimize=20 > development time, since the old "patch, compile, reboot, test" cycle = is=20 > now unnecessary with this patch. >=20 > Again, ideas/suggestions/comments are welcomed. >=20 > -- > Dominic Duval > =C9tudiant, G=E9nie Informatique > Universit=E9 de Sherbrooke >=20 >=20 From owner-netdev@oss.sgi.com Sat Mar 9 07:43:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29Fh9G00645 for netdev-outgoing; Sat, 9 Mar 2002 07:43:09 -0800 Received: from radovan.kista.gajba.net (root@[212.30.75.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29Fh1900636 for ; Sat, 9 Mar 2002 07:43:01 -0800 Received: from radovan (boris@localhost [127.0.0.1]) by radovan.kista.gajba.net (8.11.4/8.11.4) with SMTP id g29Ehqx20160; Sat, 9 Mar 2002 15:43:53 +0100 Date: Sat, 9 Mar 2002 15:43:52 +0100 From: Boris Bezlaj To: netdev Cc: kernel-janitor-discuss Subject: modular IPv4 Message-Id: <20020309154352.41cb1ea8.boris@kista.gajba.net> X-Mailer: Sylpheed version 0.5.1 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1512 Lines: 57 Hi. I tried the IPv4 module patch located at http://www-edu.gel.usherb.ca/duvd01/linux/diff-2.4.17-ipv4-0.11 and i get some errors in compilation, and later at depmod. I applied it against 2.4.19-pre2-ac3 (no errors). Before the patch i had no such errors.. 1. compile errors: ipip.c and ip_gre.c (did not have those errors before modular IPv4 patch) I have both ipip.o and ip_gre.o configured as modules. I kind-of fixed this, but i dont know if i did it right.. Look at the diffs below.. 2. Unresolved symbols: (did not have those errors before modular IPv4 patch) in modules : ip_gre.o ipip.o ip_conntrack.o ip_queue.o ipt_MASQUERADE.o ipt_MIRROR.o ipt_REJECT.o iptable_mangle.o iptable_nat.o ipv6.o kernel/net/sched/cls_fw.o kernel/net/sched/cls_route.o kernel/net/sched/sch_cbq.o I am not experienced enough to fix these.. Diffs: // ipip.diff --- net/ipv4/ipip.orig Sat Mar 9 12:32:45 2002 +++ net/ipv4/ipip.c Sat Mar 9 12:35:13 2002 @@ -94,9 +94,7 @@ #include -#if 0 #include -#endif #include #include #include // ip_gre.diff --- net/ipv4/ip_gre.orig Sat Mar 9 12:37:43 2002 +++ net/ipv4/ip_gre.c Sat Mar 9 12:42:14 2002 @@ -11,9 +11,7 @@ */ #include -#if 0 #include -#endif #include #include #include @@ -1296,5 +1294,4 @@ unregister_netdev(&ipgre_fb_tunnel_dev); } -#endif MODULE_LICENSE("GPL"); From owner-netdev@oss.sgi.com Sat Mar 9 07:49:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29FnkI00866 for netdev-outgoing; Sat, 9 Mar 2002 07:49:46 -0800 Received: from cogenit.fr (mail.cogenit.fr [195.68.53.173]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29Fni900863 for ; Sat, 9 Mar 2002 07:49:44 -0800 Received: from fafner.intra.cogenit.fr (IDENT:root@fafner.intra.cogenit.fr [192.168.1.17]) by cogenit.fr (8.12.1/8.12.1) with ESMTP id g29EnQlU016759; Sat, 9 Mar 2002 15:49:26 +0100 Received: (from romieu@localhost) by fafner.intra.cogenit.fr (8.11.2/8.12.1) id g29EnQH06721; Sat, 9 Mar 2002 15:49:26 +0100 Date: Sat, 9 Mar 2002 15:49:26 +0100 From: Francois Romieu To: Boris Bezlaj Cc: netdev , kernel-janitor-discuss Subject: Re: modular IPv4 Message-ID: <20020309154926.B6625@fafner.intra.cogenit.fr> References: <20020309154352.41cb1ea8.boris@kista.gajba.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020309154352.41cb1ea8.boris@kista.gajba.net>; from boris@kista.gajba.net on Sat, Mar 09, 2002 at 03:43:52PM +0100 X-Organisation: Marie's fan club - II Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 475 Lines: 12 Boris Bezlaj : [...] > 2. Unresolved symbols: (did not have those errors before modular IPv4 patch) > in modules : ip_gre.o ipip.o ip_conntrack.o ip_queue.o ipt_MASQUERADE.o ipt_MIRROR.o > ipt_REJECT.o iptable_mangle.o iptable_nat.o ipv6.o kernel/net/sched/cls_fw.o kernel/net/sched/cls_route.o kernel/net/sched/sch_cbq.o > > I am not experienced enough to fix these.. Could you put the (long ?) list of unresolved symbols somewhere ? -- Ueimor From owner-netdev@oss.sgi.com Sat Mar 9 11:04:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29J48v04303 for netdev-outgoing; Sat, 9 Mar 2002 11:04:08 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29J44904300 for ; Sat, 9 Mar 2002 11:04:05 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA27059; Sat, 9 Mar 2002 21:03:42 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200203091803.VAA27059@ms2.inr.ac.ru> Subject: Re: addrconf.c - possible bug To: pekkas@netcore.fi (Pekka Savola) Date: Sat, 9 Mar 2002 21:03:42 +0300 (MSK) Cc: xs26-dev@xs26.net, netdev@oss.sgi.com In-Reply-To: from "Pekka Savola" at Mar 8, 2 04:32:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 590 Lines: 19 Hello! > A problem seems to be is that ifp->probes has been overloaded for both > RS's and NS's (rtr solicits and DAD basically), It is not overload, DAD and RS are part of one process; RS follows DAD. > So there _appears_ to be a possible race there. ifp state machine is serialized with spinlock. However it does not matter: Pekka, please, reread the report; they talk about _neigbour_ _solicitations_. They have nothing to do either with ifp->probes, RS, DA or with addrconf.c at all. It is deal of ndisc.c/neghbour.c. Well, they insist that ndisc does work at all. :-) Alexey From owner-netdev@oss.sgi.com Sat Mar 9 11:40:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29JeVC04843 for netdev-outgoing; Sat, 9 Mar 2002 11:40:31 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29JeS904840 for ; Sat, 9 Mar 2002 11:40:29 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g29IeIU23295; Sat, 9 Mar 2002 20:40:18 +0200 Date: Sat, 9 Mar 2002 20:40:17 +0200 (EET) From: Pekka Savola To: kuznet@ms2.inr.ac.ru cc: xs26-dev@xs26.net, Subject: Re: addrconf.c - possible bug In-Reply-To: <200203091803.VAA27059@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 590 Lines: 13 On Sat, 9 Mar 2002 kuznet@ms2.inr.ac.ru wrote: > Pekka, please, reread the report; they talk about _neigbour_ _solicitations_. > They have nothing to do either with ifp->probes, RS, DA or with addrconf.c > at all. It is deal of ndisc.c/neghbour.c. Well, DAD *does* use neighbour solicitations. But the problem report was indeed rather unclear; at least tcpdumps would have been nice. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Sat Mar 9 12:05:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29K5Y305351 for netdev-outgoing; Sat, 9 Mar 2002 12:05:34 -0800 Received: from yue.hongo.wide.ad.jp (root@yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29K5V905347 for ; Sat, 9 Mar 2002 12:05:31 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id EAA25675; Sun, 10 Mar 2002 04:04:58 +0900 To: pekkas@netcore.fi Cc: xs26-dev@xs26.net, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: addrconf.c - possible bug In-Reply-To: References: <20020308131131.GR2198@pasky.ji.cz> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020310040458Q.yoshfuji@wide.ad.jp> Date: Sun, 10 Mar 2002 04:04:58 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 582 Lines: 14 In article (at Fri, 8 Mar 2002 16:32:55 +0200 (EET)), Pekka Savola says: > differently: DAD starts from number X (X>0) decrementing it and RS start > from (assumed to be zero), incrementing it. Sending RSs only when DAD for link-local addresses has been completed on non-loopback interfaces, and addrconf_dad_completed() set ifp->probes 1. It sets addrconf_mod_timer() and addrconf_rs_timer() will resend RSs ifp->idev->cnf.rtr_solicits - 1 times. RS and DAD are not sent at the same time. --yoshfuji From owner-netdev@oss.sgi.com Sat Mar 9 14:13:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29MDVp07970 for netdev-outgoing; Sat, 9 Mar 2002 14:13:31 -0800 Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29MDP907965 for ; Sat, 9 Mar 2002 14:13:25 -0800 Received: from dd.qc.ca ([66.130.115.91]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id GSQ5MA00.EK6; Sat, 9 Mar 2002 16:13:22 -0500 Message-ID: <3C8A7965.5010703@dd.qc.ca> Date: Sat, 09 Mar 2002 16:06:45 -0500 From: Dominic Duval User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 To: Matti Aarnio CC: netdev@oss.sgi.com Subject: Re: ipv4.o module References: <3C89C85D.9070505@dd.qc.ca> <20020309164131.D10704@mea-ext.zmailer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1548 Lines: 43 Matti Aarnio wrote: >>I recently spent some time working on the "modularization" of the ipv4 >>stack. More precisely, this allows anyone to boot the kernel without any >>ipv4 support (thus saving about 200k of RAM) and load a module >>implementing the TCP/IP stack latter on. >> > > Excellent. I had plan to do that latter this spring, but > like always, there are parallel developments. > > One of my goals is to rip the TCP and UDP into separate submodules, > so that we can in fact load in TCP, UDP and preferred IP (4 and/or 6) > layers. > Sure, that would be the next logical steps. The current patch is more a proof of concept than anything else. For example, something better could be done with ipv6, in fact I'm not even sure how the ipv6 module (and other sub-modules of ipv4) will react with all these modifications. I guess I'll need to expand the scope of the tests in the next few days. Anyway, your goals seem to fit very well with our objectives, so please don't hesitate to keep in touch with me if you make any progress. I would be more than happy to help you out and add these features to our work. >You don't (yet) have 2.5.* diffs ? > Unfortunately, this patch is built so that we can easily modify the TCP/IP stack for a project involving the 2.4.17 Kernel. Therefore the primary goal for the time being is to make the 2.4.17 ipv4 modular. I haven't tried to apply the changes to 2.5.* yet, but it's on my todo list :) Cheers, -- Dominic Duval Étudiant, Génie Informatique Université de Sherbrooke From owner-netdev@oss.sgi.com Sat Mar 9 16:00:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A00OJ10274 for netdev-outgoing; Sat, 9 Mar 2002 16:00:24 -0800 Received: from cogenit.fr (se1.cogenit.fr [195.68.53.173]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A00L910270 for ; Sat, 9 Mar 2002 16:00:21 -0800 Received: from fafner.intra.cogenit.fr (IDENT:root@fafner.intra.cogenit.fr [192.168.1.17]) by cogenit.fr (8.12.1/8.12.1) with ESMTP id g29N0IlU023062; Sun, 10 Mar 2002 00:00:18 +0100 Received: (from romieu@localhost) by fafner.intra.cogenit.fr (8.11.2/8.12.1) id g29N0I818968; Sun, 10 Mar 2002 00:00:18 +0100 Date: Sun, 10 Mar 2002 00:00:18 +0100 From: Francois Romieu To: Dominic Duval Cc: netdev@oss.sgi.com Subject: Re: ipv4.o module Message-ID: <20020310000018.F18717@fafner.intra.cogenit.fr> References: <3C89C85D.9070505@dd.qc.ca> <20020309164131.D10704@mea-ext.zmailer.org> <3C8A7965.5010703@dd.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C8A7965.5010703@dd.qc.ca>; from dd@dd.qc.ca on Sat, Mar 09, 2002 at 04:06:45PM -0500 X-Organisation: Marie's fan club - II Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 447 Lines: 12 Dominic Duval : [...] > Sure, that would be the next logical steps. The current patch is more a > proof of concept than anything else. For example, something better could > be done with ipv6, in fact I'm not even sure how the ipv6 module (and > other sub-modules of ipv4) will react with all these modifications. I On a related note, could somebody elaborate on why the EXPORT_SYMBOL are done from net/netsyms.c ? -- Ueimor From owner-netdev@oss.sgi.com Sat Mar 9 16:17:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A0Hb510770 for netdev-outgoing; Sat, 9 Mar 2002 16:17:37 -0800 Received: from zmailer.org ([195.163.186.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A0HY910766 for ; Sat, 9 Mar 2002 16:17:34 -0800 Received: (mea@mea-ext) by mail.zmailer.org id ; Sun, 10 Mar 2002 01:17:32 +0200 Date: Sun, 10 Mar 2002 01:17:31 +0200 From: Matti Aarnio To: Francois Romieu Cc: Dominic Duval , netdev@oss.sgi.com Subject: Re: ipv4.o module Message-ID: <20020310011731.F10704@mea-ext.zmailer.org> References: <3C89C85D.9070505@dd.qc.ca> <20020309164131.D10704@mea-ext.zmailer.org> <3C8A7965.5010703@dd.qc.ca> <20020310000018.F18717@fafner.intra.cogenit.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020310000018.F18717@fafner.intra.cogenit.fr>; from romieu@cogenit.fr on Sun, Mar 10, 2002 at 12:00:18AM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 789 Lines: 20 On Sun, Mar 10, 2002 at 12:00:18AM +0100, Francois Romieu wrote: > Dominic Duval : > [...] > > Sure, that would be the next logical steps. The current patch is more a > > proof of concept than anything else. For example, something better could > > be done with ipv6, in fact I'm not even sure how the ipv6 module (and > > other sub-modules of ipv4) will react with all these modifications. I > > On a related note, could somebody elaborate on why the EXPORT_SYMBOL > are done from net/netsyms.c ? Static linkage symbols of net-kind are done from there. It took some care year(s) ago to move ipv4 exports elsewere, when I did previous try at modularizing the IP stack. Some remnants may be visible at: ftp://zmailer.org/linux/ > -- > Ueimor /Matti Aarnio From owner-netdev@oss.sgi.com Sat Mar 9 16:52:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A0qMQ11439 for netdev-outgoing; Sat, 9 Mar 2002 16:52:22 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A0qI911435 for ; Sat, 9 Mar 2002 16:52:18 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA05190; Sat, 9 Mar 2002 15:49:14 -0800 Date: Sat, 09 Mar 2002 15:49:14 -0800 (PST) Message-Id: <20020309.154914.121220659.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: greearb@candelatech.com, akpm@zip.com.au, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BK PATCHES] lotsa net driver merges From: "David S. Miller" In-Reply-To: <3C87CB5C.61703012@mandrakesoft.com> References: <3C8746EC.CA7B0295@mandrakesoft.com> <3C879692.8010103@candelatech.com> <3C87CB5C.61703012@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 888 Lines: 21 From: Jeff Garzik Date: Thu, 07 Mar 2002 15:19:40 -0500 Ben Greear wrote: > In case you are using intel's 1.8.37 driver, I can cause a kernel panic > in it by trying to reset the transceiver through MII IOCTLs.. I've > been passing email with their support, so hopefully it will be resolved > soon. ... Anyway, this is e100 version 2.0.19, with lots of changes by the Intel folks at my request. Ben, I'm going to put your report in the same classification as "root cat'd crap into /dev/kmem and the kernel crashed". If you are programming the PHY directly with MII IOCTLs you are on your own. I personally refuse to monitor how the user pokes at the MII in my drivers to try and cope with the user putting the PHY into a weird state that the driver would otherwise never need to deal with. It is not a bug, pure and simple. From owner-netdev@oss.sgi.com Sat Mar 9 17:05:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A15SZ11848 for netdev-outgoing; Sat, 9 Mar 2002 17:05:28 -0800 Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A15P911843 for ; Sat, 9 Mar 2002 17:05:25 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 88B0F1A9588; Sat, 9 Mar 2002 16:04:34 -0800 (PST) Date: Sat, 9 Mar 2002 16:04:34 -0800 From: Chris Wedgwood To: Matti Aarnio Cc: Dominic Duval , netdev@oss.sgi.com Subject: Re: ipv4.o module Message-ID: <20020310000434.GA1266@tapu.f00f.org> References: <3C89C85D.9070505@dd.qc.ca> <20020309164131.D10704@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020309164131.D10704@mea-ext.zmailer.org> User-Agent: Mutt/1.3.27i X-No-Archive: Yes Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 853 Lines: 24 On Sat, Mar 09, 2002 at 04:41:31PM +0200, Matti Aarnio wrote: Excellent. I had plan to do that latter this spring, but like always, there are parallel developments. There are at least three sets of patches like this floating about (I did this some time ago and so did Adam Richter (sp?)). One thing that is really nice is that is allow debugging/tweaking without having to reboot (although that's much less of an issue for me now). One of my goals is to rip the TCP and UDP into separate submodules, so that we can in fact load in TCP, UDP and preferred IP (4 and/or 6) layers. I considered this when I modularized things and opted not to as I couldn't see any real benefit in doing so... ideally you need ipv4_core.o (ipv4 + icmp), ipv4_tcp, ipv4_udp and such like. However, is this really use to anyone? --cw From owner-netdev@oss.sgi.com Sat Mar 9 17:11:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A1BHJ12116 for netdev-outgoing; Sat, 9 Mar 2002 17:11:17 -0800 Received: from zmailer.org ([195.163.186.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A1BD912113 for ; Sat, 9 Mar 2002 17:11:13 -0800 Received: (mea@mea-ext) by mail.zmailer.org id ; Sun, 10 Mar 2002 02:11:11 +0200 Date: Sun, 10 Mar 2002 02:11:11 +0200 From: Matti Aarnio To: Chris Wedgwood Cc: netdev@oss.sgi.com Subject: Re: ipv4.o module Message-ID: <20020310021111.G10704@mea-ext.zmailer.org> References: <3C89C85D.9070505@dd.qc.ca> <20020309164131.D10704@mea-ext.zmailer.org> <20020310000434.GA1266@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020310000434.GA1266@tapu.f00f.org>; from cw@f00f.org on Sat, Mar 09, 2002 at 04:04:34PM -0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 751 Lines: 20 On Sat, Mar 09, 2002 at 04:04:34PM -0800, Chris Wedgwood wrote: > On Sat, Mar 09, 2002 at 04:41:31PM +0200, Matti Aarnio wrote: .... > One of my goals is to rip the TCP and UDP into separate submodules, > so that we can in fact load in TCP, UDP and preferred IP (4 and/or 6) > layers. > > I considered this when I modularized things and opted not to as I > couldn't see any real benefit in doing so... ideally you need > ipv4_core.o (ipv4 + icmp), ipv4_tcp, ipv4_udp and such like. However, > is this really use to anyone? A pure IPv6 only system is the goal I had in mind. The IPv6 does happen to need TCP and UDP, which even use shared port number spaces (quite a complicated thing, actually.) > --cw /Matti Aarnio From owner-netdev@oss.sgi.com Sat Mar 9 17:30:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A1UkO12547 for netdev-outgoing; Sat, 9 Mar 2002 17:30:46 -0800 Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A1Uh912544 for ; Sat, 9 Mar 2002 17:30:43 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id CAFDA1A9587; Sat, 9 Mar 2002 16:29:52 -0800 (PST) Date: Sat, 9 Mar 2002 16:29:52 -0800 From: Chris Wedgwood To: Matti Aarnio Cc: netdev@oss.sgi.com Subject: Re: ipv4.o module Message-ID: <20020310002952.GA1325@tapu.f00f.org> References: <3C89C85D.9070505@dd.qc.ca> <20020309164131.D10704@mea-ext.zmailer.org> <20020310000434.GA1266@tapu.f00f.org> <20020310021111.G10704@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020310021111.G10704@mea-ext.zmailer.org> User-Agent: Mutt/1.3.27i X-No-Archive: Yes Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 435 Lines: 13 On Sun, Mar 10, 2002 at 02:11:11AM +0200, Matti Aarnio wrote: A pure IPv6 only system is the goal I had in mind. The IPv6 does happen to need TCP and UDP, which even use shared port number spaces (quite a complicated thing, actually.) Ah, well then we need ipv4_core.o, ip_tcp_udp.o and ipv6_core.o sort of thing (you can't separate ICMP and ICMP6 from the core.o modules and the others depend on this). --cw From owner-netdev@oss.sgi.com Sat Mar 9 19:06:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A36GB15073 for netdev-outgoing; Sat, 9 Mar 2002 19:06:16 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A36A915069 for ; Sat, 9 Mar 2002 19:06:10 -0800 Received: (qmail 29563 invoked from network); 10 Mar 2002 02:06:08 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 10 Mar 2002 02:06:08 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E8A7A3000BA; Sun, 10 Mar 2002 12:06:05 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B9A04BA; Sun, 10 Mar 2002 13:06:05 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Francois Romieu Cc: Dominic Duval , netdev@oss.sgi.com Subject: Re: ipv4.o module In-reply-to: Your message of "Sun, 10 Mar 2002 00:00:18 BST." <20020310000018.F18717@fafner.intra.cogenit.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Mar 2002 13:06:00 +1100 Message-ID: <23576.1015725960@ocs3.intra.ocs.com.au> Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1192 Lines: 28 On Sun, 10 Mar 2002 00:00:18 +0100, Francois Romieu wrote: >Dominic Duval : >[...] >> Sure, that would be the next logical steps. The current patch is more a >> proof of concept than anything else. For example, something better could >> be done with ipv6, in fact I'm not even sure how the ipv6 module (and >> other sub-modules of ipv4) will react with all these modifications. I > >On a related note, could somebody elaborate on why the EXPORT_SYMBOL >are done from net/netsyms.c ? Historical reasons. The original method of exporting symbols required header and trailer X macros and it was easier to have one file per subsystem that did all the exports. With EXPORT_SYMBOL you can export the symbols directly from the file that instantiates the symbol, subject to these constraints :- Files that use EXPORT_SYMBOL must be in the export-objs list in the Makefile. Files that use EXPORT_SYMBOL must have a globably unique name. You cannot export from inode.c because there are multiple files called inode.c. There is a minor problem with the kernel build that recompiles all files in the directory that export symbols if any file has changed. From owner-netdev@oss.sgi.com Sat Mar 9 19:19:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A3Jk315396 for netdev-outgoing; Sat, 9 Mar 2002 19:19:46 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g2A3Jj915393 for ; Sat, 9 Mar 2002 19:19:45 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2A2JiU05094 for netdev@oss.sgi.com; Sat, 9 Mar 2002 18:19:44 -0800 Received: from grok.yi.org (ip68-3-107-226.ph.ph.cox.net [68.3.107.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27INp910284 for ; Thu, 7 Mar 2002 10:23:52 -0800 Received: from candelatech.com ([66.89.142.2]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g27HM7O16159; Thu, 7 Mar 2002 10:22:17 -0700 Message-ID: <3C879692.8010103@candelatech.com> Date: Thu, 07 Mar 2002 09:34:26 -0700 From: Ben Greear Organization: Candela Technologies Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jeff Garzik CC: "David S. Miller" , Andrew Morton , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BK PATCHES] lotsa net driver merges References: <3C8746EC.CA7B0295@mandrakesoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 17912 Lines: 486 Jeff Garzik wrote: > Linus, > > A bunch of net driver changes, few noteworthy. The interesting changes: > > 1) Add two helpers to PCI API, pci_set_mwi and pci_clear_mwi, for > enabling and disabling Memory-Write-Invalidate transcations. This is > really just a cleanup, moving code that existed in drivers/net/* for a > long time into drivers/pci where it belongs. > > GNU PATCH ATTACHED for reference and review > > 2) Add new gige driver tg3 > > 3) Add new 10/100 driver e100 In case you are using intel's 1.8.37 driver, I can cause a kernel panic in it by trying to reset the transceiver through MII IOCTLs.. I've been passing email with their support, so hopefully it will be resolved soon. > > 4) Move tulip clone drivers into drivers/net/tulip. -No changes-, just > moves the files. Eventually they will be able to share code and such > nifty things... > > > > ------------------------------------------------------------------------ > > > Linus, > > Please do a > > bk pull http://gkernel.bkbits.net/net-drivers-2.5 > > to receive a whole bunch of net driver changes. > > > > > ChangeSet@1.493, 2002-03-07 05:35:22-05:00, jgarzik@mandrakesoft.com > Move dmfe, winbond-840, xircom_cb, xircom_tulip_cb, de2104x and de4x5 > net drivers to drivers/net/tulip directory. > > drivers/net/de2104x.c | 2240 ------------- > drivers/net/de4x5.c | 5918 ----------------------------------- > drivers/net/de4x5.h | 1031 ------ > drivers/net/dmfe.c | 2070 ------------ > drivers/net/pcmcia/xircom_cb.c | 1245 ------- > drivers/net/pcmcia/xircom_tulip_cb.c | 1744 ---------- > drivers/net/winbond-840.c | 1757 ---------- > Makefile | 1 > drivers/net/Config.help | 83 > drivers/net/Config.in | 12 > drivers/net/Makefile | 13 > drivers/net/pcmcia/Config.in | 5 > drivers/net/pcmcia/Makefile | 5 > drivers/net/tulip/Config.help | 110 > drivers/net/tulip/Config.in | 27 > drivers/net/tulip/Makefile | 39 > drivers/net/tulip/de2104x.c | 2240 +++++++++++++ > drivers/net/tulip/de4x5.c | 5918 +++++++++++++++++++++++++++++++++++ > drivers/net/tulip/de4x5.h | 1031 ++++++ > drivers/net/tulip/dmfe.c | 2070 ++++++++++++ > drivers/net/tulip/winbond-840.c | 1757 ++++++++++ > drivers/net/tulip/xircom_cb.c | 1245 +++++++ > drivers/net/tulip/xircom_tulip_cb.c | 1744 ++++++++++ > 23 files changed, 16178 insertions(+), 16127 deletions(-) > > > ChangeSet@1.492, 2002-03-07 04:41:44-05:00, jgarzik@mandrakesoft.com > Update starfire and tulip net drivers to use new PCI API functions > pci_set_mwi and pci_clear_mwi. > > drivers/net/starfire.c | 15 ++++++--- > drivers/net/tulip/ChangeLog | 7 ++++ > drivers/net/tulip/tulip_core.c | 65 ++++++++++++++++++----------------------- > 3 files changed, 48 insertions(+), 39 deletions(-) > > > ChangeSet@1.491, 2002-03-07 04:22:59-05:00, jgarzik@mandrakesoft.com > Revert to older xircom_cb net driver. This older one is far > more reliable in testing, and works for all cases as near as > everyone can tell. > > Contributor: Arjan @ RedHat > > drivers/net/pcmcia/xircom_cb.c | 660 +++++++++++++++-------------------------- > 1 files changed, 247 insertions(+), 413 deletions(-) > > > ChangeSet@1.490, 2002-03-07 03:48:44-05:00, jgarzik@mandrakesoft.com > Merge Intel EtherExpress PRO/100 net driver "e100" from Intel, > version 2.0.19, plus boolean cleanups. > Bump version to 2.0.20-pre1. > > Contributors: Eli Kupermann @ Intel, Amir Noam @ Intel > > drivers/net/Config.in | 3 > drivers/net/Makefile | 4 > drivers/net/e100/Makefile | 16 > drivers/net/e100/e100.h | 1033 +++++++++++ > drivers/net/e100/e100_config.c | 596 ++++++ > drivers/net/e100/e100_config.h | 206 ++ > drivers/net/e100/e100_eeprom.c | 614 ++++++ > drivers/net/e100/e100_main.c | 3797 +++++++++++++++++++++++++++++++++++++++++ > drivers/net/e100/e100_phy.c | 1133 ++++++++++++ > drivers/net/e100/e100_phy.h | 183 + > drivers/net/e100/e100_proc.c | 925 +++++++++ > drivers/net/e100/e100_ucode.h | 411 ++++ > drivers/net/e100/e100_vendor.h | 348 +++ > 13 files changed, 9268 insertions(+), 1 deletion(-) > > > ChangeSet@1.489, 2002-03-07 03:20:03-05:00, jgarzik@mandrakesoft.com > Merge new tg3 version 0.96 gigabit ethernet driver. > > Documentation/networking/driver.txt | 84 > drivers/net/Config.help | 8 > drivers/net/Config.in | 1 > drivers/net/Makefile | 1 > drivers/net/tg3.c | 5925 ++++++++++++++++++++++++++++++++++++ > drivers/net/tg3.h | 1851 +++++++++++ > drivers/pci/pci.ids | 18 > include/linux/pci_ids.h | 7 > 8 files changed, 7895 insertions(+) > > > ChangeSet@1.488, 2002-03-07 02:26:01-05:00, go@turbolinux.co.jp > Update pcnet32 net driver with the following changes: > v1.27 improved CSR/PROM address detection, lots of cleanups, > new pcnet32vlb module option, HP-PARISC support, > added module parameter descriptions, > initial ethtool support - Helge Deller > v1.27a Sun Feb 10 2002 Go Taniguchi > use alloc_etherdev and register_netdev > fix pci probe not increment cards_found > FD auto negotiate error workaround for xSeries250 > clean up and using new mii module > > drivers/net/pcnet32.c | 412 ++++++++++++++++++++++++-------------------------- > 1 files changed, 203 insertions(+), 209 deletions(-) > > > ChangeSet@1.487, 2002-03-07 02:18:29-05:00, davej@suse.de > Add dev->last_rx = jiffies at time of raw interface packet receive, > for the following net drivers: > > Several ham radio, several IrDA, lp4863, pcnet32, saa9730, > wireless orinoco. > > drivers/net/hamradio/6pack.c | 1 + > drivers/net/hamradio/baycom_epp.c | 1 + > drivers/net/hamradio/bpqether.c | 1 + > drivers/net/hamradio/hdlcdrv.c | 1 + > drivers/net/hamradio/mkiss.c | 1 + > drivers/net/hamradio/scc.c | 1 + > drivers/net/hamradio/yam.c | 1 + > drivers/net/irda/ali-ircc.c | 1 + > drivers/net/irda/irda-usb.c | 1 + > drivers/net/irda/nsc-ircc.c | 1 + > drivers/net/irda/smc-ircc.c | 1 + > drivers/net/irda/toshoboe.c | 4 +++- > drivers/net/irda/vlsi_ir.c | 1 + > drivers/net/irda/w83977af_ir.c | 1 + > drivers/net/lp486e.c | 1 + > drivers/net/pcnet32.c | 1 + > drivers/net/saa9730.c | 1 + > drivers/net/wireless/orinoco.c | 1 + > 18 files changed, 20 insertions(+), 1 deletion(-) > > > ChangeSet@1.486, 2002-03-07 02:08:23-05:00, p_gortmaker@yahoo.com > MODULE_DESC net drivers cleanup. > > Idea is that if there is a valid name in MODULE_DESCRIPTION("...") > then the name of the hardware/driver should not be also repeated > in each MODULE_PARM_DESC("..."). MODULE_DESCRIPTION has been > added to essentially all the 8390 drivers. > > All of the drivers changed are 8390 based, with the exception of > eepro100 and 3c509. > > drivers/net/3c503.c | 9 +++++---- > drivers/net/3c509.c | 11 ++++++----- > drivers/net/ac3200.c | 9 +++++---- > drivers/net/e2100.c | 11 ++++++----- > drivers/net/eepro100.c | 22 +++++++++++----------- > drivers/net/es3210.c | 9 +++++---- > drivers/net/hp-plus.c | 7 ++++--- > drivers/net/hp.c | 7 ++++--- > drivers/net/lne390.c | 7 ++++--- > drivers/net/ne.c | 9 +++++---- > drivers/net/ne2k-pci.c | 6 +++--- > drivers/net/ne3210.c | 9 +++++---- > drivers/net/smc-ultra.c | 7 ++++--- > drivers/net/smc-ultra32.c | 4 +++- > drivers/net/wd.c | 9 +++++---- > 15 files changed, 75 insertions(+), 61 deletions(-) > > > ChangeSet@1.485, 2002-03-07 02:02:52-05:00, brownfld@irridia.com > Update SysKonnect gigabit ethernet driver to support > the second port on dual-port SK-9844 NICs. > > drivers/net/sk98lin/skge.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 42 insertions(+) > > > ChangeSet@1.484, 2002-03-07 01:59:32-05:00, sebastian.droege@gmx.de > Fix dmfe net driver build with newer binutils. > > drivers/net/dmfe.c | 2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) > > > ChangeSet@1.483, 2002-03-07 01:55:49-05:00, key@austin.ibm.com > lanstreamer token ring driver update: > 08/15/01 - Added ioctl() functionality for debugging, changed netif_*_queue > calls and other incorrectness - Kent Yoder > 11/05/01 - Restructured the interrupt function, added delays, reduced the > the number of TX descriptors to 1, which together can prevent > the card from locking up the box - > > drivers/net/tokenring/lanstreamer.c | 230 ++++++++++++++++++++++++++++-------- > drivers/net/tokenring/lanstreamer.h | 34 +++++ > 2 files changed, 212 insertions(+), 52 deletions(-) > > > ChangeSet@1.482, 2002-03-07 01:52:56-05:00, davej@suse.de > Fix 3c505 net driver merge error: > Remove duplicated ethtool ioctl handling code, fixing build. > > drivers/net/3c505.c | 81 ---------------------------------------------------- > 1 files changed, 81 deletions(-) > > > ChangeSet@1.481, 2002-03-06 21:47:46-05:00, jgarzik@mandrakesoft.com > s/foo/DE4X5_foo/ in de4x5 net driver, to fix conflict > with public namespace. > > drivers/net/de4x5.c | 32 ++++++++++++++++---------------- > 1 files changed, 16 insertions(+), 16 deletions(-) > > > ChangeSet@1.480, 2002-03-06 21:38:57-05:00, jgarzik@mandrakesoft.com > Hand merge. > > include/linux/compiler.h | 3 +-- > 1 files changed, 1 insertion(+), 2 deletions(-) > > > ChangeSet@1.472.1.5, 2002-03-06 21:23:59-05:00, jgarzik@mandrakesoft.com > Add new architecture PCI API function helper, pdev_set_mwi(). > Add new PCI API functions pci_set_mwi(), pci_clear_mwi(). > > Documentation/pci.txt | 7 +++ > drivers/pci/pci.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++ > include/linux/pci.h | 4 ++ > 3 files changed, 109 insertions(+) > > > ChangeSet@1.472.1.4, 2002-03-06 19:56:34-05:00, jgarzik@mandrakesoft.com > Typo fix for linux/compiler.h. > (a few csets later on this is auto-merged away) > > include/linux/compiler.h | 2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) > > > ChangeSet@1.472.1.3, 2002-03-06 17:15:35-05:00, ionut@cs.columbia.edu > starfire net driver updates: > * Sparc64 support and fixes. > * Better stats and error handling. > > drivers/net/Config.in | 2 - > drivers/net/starfire.c | 59 ++++++++++++++++++++++++++++++++++--------------- > 2 files changed, 43 insertions(+), 18 deletions(-) > > > ChangeSet@1.472.1.2, 2002-03-06 17:08:49-05:00, jgarzik@mandrakesoft.com > s/kfree/kfree_skb/ in drivers/s390/net/ctctty.c. > Contributor forgotten :( > > drivers/s390/net/ctctty.c | 2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) > > > ChangeSet@1.422.1.9, 2002-03-02 02:06:00-05:00, jgarzik@mandrakesoft.com > Update e1000 net driver to not EXPORT_SYMBOL > the standard net driver interface. > > drivers/net/e1000/e1000_main.c | 19 +------------------ > 1 files changed, 1 insertion(+), 18 deletions(-) > > > ChangeSet@1.422.1.8, 2002-02-28 04:46:11-05:00, jgarzik@mandrakesoft.com > Update 8139cp net driver for the following: > * Merge VLAN defines and support from vger, ifdef'd out until > API appears in main tree. > * Support RX checksumming. > * Correct CP_MAX_MTU. > * Clarify CP_MIN_MTU issues. > > drivers/net/8139cp.c | 122 ++++++++++++++++++++++++++++++++++++++++++--------- > 1 files changed, 102 insertions(+), 20 deletions(-) > > > > > ------------------------------------------------------------------------ > > diff -Nru a/Documentation/pci.txt b/Documentation/pci.txt > --- a/Documentation/pci.txt Thu Mar 7 05:42:40 2002 > +++ b/Documentation/pci.txt Thu Mar 7 05:42:40 2002 > @@ -156,6 +156,11 @@ > which enables the bus master bit in PCI_COMMAND register and also fixes > the latency timer value if it's set to something bogus by the BIOS. > > + If you want to use the PCI Memory-Write-Invalidate transaction, > +call pci_set_mwi(). This enables bit PCI_COMMAND bit for Mem-Wr-Inval > +and also ensures that the cache line size register is set correctly. > +Make sure to check the return value of pci_set_mwi(), not all architectures > +may support Memory-Write-Invalidate. > > 4. How to access PCI config space > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > @@ -202,6 +207,8 @@ > pci_resource_len() Returns the byte length of a PCI region > pci_set_drvdata() Set private driver data pointer for a pci_dev > pci_get_drvdata() Return private driver data pointer for a pci_dev > +pci_set_mwi() Enable Memory-Write-Invalidate transactions. > +pci_clear_mwi() Disable Memory-Write-Invalidate transactions. > > > 7. Miscellaneous hints > diff -Nru a/drivers/pci/pci.c b/drivers/pci/pci.c > --- a/drivers/pci/pci.c Thu Mar 7 05:42:40 2002 > +++ b/drivers/pci/pci.c Thu Mar 7 05:42:40 2002 > @@ -23,6 +23,7 @@ > #include /* for hotplug_path */ > #include > #include > +#include > > #include > #include /* isa_dma_bridge_buggy */ > @@ -848,6 +849,100 @@ > pcibios_set_master(dev); > } > > +/** > + * pdev_set_mwi - arch helper function for pcibios_set_mwi > + * @dev: the PCI device for which MWI is enabled > + * > + * Helper function for implementation the arch-specific pcibios_set_mwi > + * function. Originally copied from drivers/net/acenic.c. > + * Copyright 1998-2001 by Jes Sorensen, . > + * > + * RETURNS: An appriopriate -ERRNO error value on eror, or zero for success. > + */ > +int > +pdev_set_mwi(struct pci_dev *dev) > +{ > + int rc = 0; > + u8 cache_size; > + > + /* > + * Looks like this is necessary to deal with on all architectures, > + * even this %$#%$# N440BX Intel based thing doesn't get it right. > + * Ie. having two NICs in the machine, one will have the cache > + * line set at boot time, the other will not. > + */ > + pci_read_config_byte(dev, PCI_CACHE_LINE_SIZE, &cache_size); > + cache_size <<= 2; > + if (cache_size != SMP_CACHE_BYTES) { > + printk(KERN_WARNING "PCI: %s PCI cache line size set incorrectly " > + "(%i bytes) by BIOS/FW, ", > + dev->slot_name, cache_size); > + if (cache_size > SMP_CACHE_BYTES) { > + printk("expecting %i\n", SMP_CACHE_BYTES); > + rc = -EINVAL; > + } else { > + printk("correcting to %i\n", SMP_CACHE_BYTES); > + pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, > + SMP_CACHE_BYTES >> 2); > + } > + } > + > + return rc; > +} > + > +/** > + * pci_set_mwi - enables memory-write-validate PCI transaction > + * @dev: the PCI device for which MWI is enabled > + * > + * Enables the Memory-Write-Invalidate transaction in %PCI_COMMAND, > + * and then calls @pcibios_set_mwi to do the needed arch specific > + * operations or a generic mwi-prep function. > + * > + * RETURNS: An appriopriate -ERRNO error value on eror, or zero for success. > + */ > +int > +pci_set_mwi(struct pci_dev *dev) > +{ > + int rc; > + u16 cmd; > + > +#ifdef HAVE_ARCH_PCI_MWI > + rc = pcibios_set_mwi(dev); > +#else > + rc = pdev_set_mwi(dev); > +#endif > + > + if (rc) > + return rc; > + > + pci_read_config_word(dev, PCI_COMMAND, &cmd); > + if (! (cmd & PCI_COMMAND_INVALIDATE)) { > + DBG("PCI: Enabling Mem-Wr-Inval for device %s\n", dev->slot_name); > + cmd |= PCI_COMMAND_INVALIDATE; > + pci_write_config_word(dev, PCI_COMMAND, cmd); > + } > + > + return 0; > +} > + > +/** > + * pci_clear_mwi - disables Memory-Write-Invalidate for device dev > + * @dev: the PCI device to disable > + * > + * Disables PCI Memory-Write-Invalidate transaction on the device > + */ > +void > +pci_clear_mwi(struct pci_dev *dev) > +{ > + u16 cmd; > + > + pci_read_config_word(dev, PCI_COMMAND, &cmd); > + if (cmd & PCI_COMMAND_INVALIDATE) { > + cmd &= ~PCI_COMMAND_INVALIDATE; > + pci_write_config_word(dev, PCI_COMMAND, cmd); > + } > +} > + > int > pci_set_dma_mask(struct pci_dev *dev, u64 mask) > { > @@ -2002,6 +2097,9 @@ > EXPORT_SYMBOL(pci_find_slot); > EXPORT_SYMBOL(pci_find_subsys); > EXPORT_SYMBOL(pci_set_master); > +EXPORT_SYMBOL(pci_set_mwi); > +EXPORT_SYMBOL(pci_clear_mwi); > +EXPORT_SYMBOL(pdev_set_mwi); > EXPORT_SYMBOL(pci_set_dma_mask); > EXPORT_SYMBOL(pci_dac_set_dma_mask); > EXPORT_SYMBOL(pci_assign_resource); > diff -Nru a/include/linux/pci.h b/include/linux/pci.h > --- a/include/linux/pci.h Thu Mar 7 05:42:40 2002 > +++ b/include/linux/pci.h Thu Mar 7 05:42:40 2002 > @@ -564,6 +564,10 @@ > int pci_enable_device(struct pci_dev *dev); > void pci_disable_device(struct pci_dev *dev); > void pci_set_master(struct pci_dev *dev); > +#define HAVE_PCI_SET_MWI > +int pci_set_mwi(struct pci_dev *dev); > +void pci_clear_mwi(struct pci_dev *dev); > +int pdev_set_mwi(struct pci_dev *dev); > int pci_set_dma_mask(struct pci_dev *dev, u64 mask); > int pci_dac_set_dma_mask(struct pci_dev *dev, u64 mask); > int pci_assign_resource(struct pci_dev *dev, int i); > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Sat Mar 9 19:26:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A3QAf15551 for netdev-outgoing; Sat, 9 Mar 2002 19:26:10 -0800 Received: from zmailer.org ([195.163.186.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A3Q6915548 for ; Sat, 9 Mar 2002 19:26:07 -0800 Received: (mea@mea-ext) by mail.zmailer.org id ; Sun, 10 Mar 2002 04:26:03 +0200 Date: Sun, 10 Mar 2002 04:26:03 +0200 From: Matti Aarnio To: Chris Wedgwood Cc: netdev@oss.sgi.com Subject: Re: ipv4.o module Message-ID: <20020310042603.H10704@mea-ext.zmailer.org> References: <3C89C85D.9070505@dd.qc.ca> <20020309164131.D10704@mea-ext.zmailer.org> <20020310000434.GA1266@tapu.f00f.org> <20020310021111.G10704@mea-ext.zmailer.org> <20020310002952.GA1325@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020310002952.GA1325@tapu.f00f.org>; from cw@f00f.org on Sat, Mar 09, 2002 at 04:29:52PM -0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1062 Lines: 26 On Sat, Mar 09, 2002 at 04:29:52PM -0800, Chris Wedgwood wrote: > On Sun, Mar 10, 2002 at 02:11:11AM +0200, Matti Aarnio wrote: > > A pure IPv6 only system is the goal I had in mind. The IPv6 > does happen to need TCP and UDP, which even use shared port > number spaces (quite a complicated thing, actually.) > > Ah, well then we need ipv4_core.o, ip_tcp_udp.o and ipv6_core.o sort > of thing (you can't separate ICMP and ICMP6 from the core.o modules > and the others depend on this). Something like that. I think there are things like timer management for tcp retransmissions, and such things which fall into "generic-ip" category, but there are also a lot of IPv4/IPv6 specific things. We can probably create a system where ipv4_core.o depends on ip_tcp_udp.o, and same with ipv6_core.o. However ipv6_core.o must not depend on ipv4_core.o -- it does now. Some hooks are called for so that _optional_ loading of ipv4 into the system, and integration with already loaded ipv6 is possible. > --cw /Matti Aarnio From owner-netdev@oss.sgi.com Sat Mar 9 20:12:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A4CUE16470 for netdev-outgoing; Sat, 9 Mar 2002 20:12:30 -0800 Received: from hades.web-sale.dk (IDENT:qmailr@[213.129.27.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A4CL916465 for ; Sat, 9 Mar 2002 20:12:22 -0800 Received: (qmail 13784 invoked by uid 1002); 10 Mar 2002 03:05:49 -0000 Date: Sun, 10 Mar 2002 04:05:48 +0100 From: Jan Oravec To: Pekka Savola Cc: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, xs26-dev@xs26.net Subject: Re: addrconf.c - possible bug Message-ID: <20020310030548.GA9466@hades.xs26.net> Reply-To: Jan Oravec References: <200203091803.VAA27059@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: UNIX Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4362 Lines: 63 On Sat, Mar 09, 2002 at 08:40:17PM +0200, Pekka Savola wrote: > On Sat, 9 Mar 2002 kuznet@ms2.inr.ac.ru wrote: > > Pekka, please, reread the report; they talk about _neigbour_ _solicitations_. > > They have nothing to do either with ifp->probes, RS, DA or with addrconf.c > > at all. It is deal of ndisc.c/neghbour.c. > > Well, DAD *does* use neighbour solicitations. But the problem report was > indeed rather unclear; at least tcpdumps would have been nice. We hadn't log files until now, because this problem happens about once per 2-3 days. Here is example of tcpdump log... fe80::201:2ff:fedc:d28c is FreeBSD box fe80::3e18:401b is Linux box (2.4.18) after some time without any problem it started to answer with redirect instead of neighbor advertisement. #tcpdump -i gif0 -n icmp6 04:42:40.187050 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:40.223644 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:40.224794 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:40.226296 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address 04:42:43.153497 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:43.155932 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address 04:42:48.163389 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:48.165887 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address 04:42:48.187078 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:48.223145 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:48.224310 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:48.225498 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address 04:42:49.187140 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:49.254335 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:49.255499 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:49.256756 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address 04:42:50.187153 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:50.223507 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:50.224670 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:50.225903 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address 04:42:53.173822 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:53.176228 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address 04:42:58.183879 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:58.186347 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address 04:42:58.187231 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:58.223651 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:58.224813 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:58.225999 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address 04:42:59.187289 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:59.223323 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 04:42:59.224475 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 04:42:59.225722 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address Best Regards, -- Jan Oravec project coordinator XS26 - 'Access to IPv6' http://www.xs26.net jan.oravec@xs26.net From owner-netdev@oss.sgi.com Sat Mar 9 23:27:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A7Rtn20017 for netdev-outgoing; Sat, 9 Mar 2002 23:27:55 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A7Rn920008 for ; Sat, 9 Mar 2002 23:27:49 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2A6Rcl01770; Sun, 10 Mar 2002 08:27:39 +0200 Date: Sun, 10 Mar 2002 08:27:38 +0200 (EET) From: Pekka Savola To: Jan Oravec cc: netdev@oss.sgi.com, , Subject: Re: addrconf.c - possible bug In-Reply-To: <20020310030548.GA9466@hades.xs26.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1817 Lines: 41 On Sun, 10 Mar 2002, Jan Oravec wrote: > On Sat, Mar 09, 2002 at 08:40:17PM +0200, Pekka Savola wrote: > > On Sat, 9 Mar 2002 kuznet@ms2.inr.ac.ru wrote: > > > Pekka, please, reread the report; they talk about _neigbour_ _solicitations_. > > > They have nothing to do either with ifp->probes, RS, DA or with addrconf.c > > > at all. It is deal of ndisc.c/neghbour.c. > > > > Well, DAD *does* use neighbour solicitations. But the problem report was > > indeed rather unclear; at least tcpdumps would have been nice. > > We hadn't log files until now, because this problem happens about once per 2-3 days. > > Here is example of tcpdump log... > > fe80::201:2ff:fedc:d28c is FreeBSD box > fe80::3e18:401b is Linux box (2.4.18) > > after some time without any problem it started to answer with redirect > instead of neighbor advertisement. > > #tcpdump -i gif0 -n icmp6 > > 04:42:40.187050 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b > 04:42:40.223644 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b > 04:42:40.224794 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b > 04:42:40.226296 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address I think I've seen something similar to this before, and IIRC it was caused by the fact that loopback interface had been brought down. If loopback has been taken down and is back up, IIRC the addresses of the interfaces must be "refreshed" (e.g. by also taking the interfaces down and up). HTH, -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Sun Mar 10 13:56:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ALupj10779 for netdev-outgoing; Sun, 10 Mar 2002 13:56:51 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ALug910775 for ; Sun, 10 Mar 2002 13:56:42 -0800 Received: from marajade.sandelman.ottawa.on.ca (wlan70.sandelman.ottawa.on.ca [192.139.46.70] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g2AKucC07845 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 10 Mar 2002 15:56:40 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g2AKpUs00212 for ; Sun, 10 Mar 2002 15:51:36 -0500 (EST) Message-Id: <200203102051.g2AKpUs00212@marajade.sandelman.ottawa.on.ca> To: netdev@oss.sgi.com Subject: skb_clone/copy on 2.2 and tcpdump/iptraf (SOCK_PACKET) Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 10 Mar 2002 15:51:29 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3017 Lines: 73 -----BEGIN PGP SIGNED MESSAGE----- The FreeSWAN KLIPS code has an explicit exception for packets originating from the localhost that are bound to UDP port 500. This is the ISAKMP port which is needed for keying the tunnels. On 2.2(.20), (but not 2.4) when a process has a SOCK_PACKET open to see outgoing traffic, the skb->sk pointer is not copied by whatever code copies and/or clones the skb. ** I am having difficulty finding that code, btw. Pointers welcome. ** We prefer to check skb->sk to implement our exception, since this guarantees the packet is from the local stack, and it gets around problems of packet fragmentation that would otherwise prevent us from seeing the port numbers. A user has noticed that he is unable to key his tunnels properly when running iptraf, which is how we noticed this. We already knew that tcpdump'ing oneself was usually a bad idea on 2.0 and 2.2, but never was quite clear why. We suspect that there is no solution to this if it is in fact a limitation of 2.2's skb_copy. (We might be able to offer a patch for a potential 2.2.21). ** can someone confirm that this is in fact the case? ** As we want to move toward using advanced routing to do this kind of thing, I tried to build an exception using ipchains and advanced routing. I did not succeed, and am not clear how to debug. I'm joining the LARTC list and reviewing the archives. Since Advance routing does not have selectors for ports, I used ipchains to set the fwmark and selected based upon that. elros:~# grep IKE /etc/iproute2/rt_tables 50 IKE elros:~# ip rule ls 0: from all lookup local 32764: from all fwmark 32 lookup IKE 32766: from all lookup main 32767: from all lookup default elros:~# ipchains -I forward 1 -i ipsec0 --proto udp --src 192.139.46.5/32 500 --dst 192.139.46.7/32 500 --mark 32 -j ACCEPT elros:~# ipchains -I output 1 --proto udp --src 192.139.46.5/32 500 --dst 192.139.46.7/32 500 --mark 32 -j ACCEPT elros:~# ip route show 192.139.46.7 via 192.139.46.1 dev ipsec0 192.139.46.56/29 dev eth1 proto kernel scope link src 192.139.46.57 192.139.46.0/28 dev eth0 proto kernel scope link src 192.139.46.5 192.139.46.0/28 dev ipsec0 proto kernel scope link src 192.139.46.5 default via 192.139.46.1 dev eth0 elros:~# ip route show table IKE 192.139.46.7 via 192.139.46.1 dev eth0 ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPIvHUIqHRg3pndX9AQHuJwP/YprWymrxR/qEcn8fOdiNEIwkJ8mQ6mbn PF3Gcsr/eBmNkISNRyXqZ/d/0a/SBPYRqTq2v2IXJ5uvCuUEd2aLEKUTwozA1Gl6 vOLqdry4dT9/7Kx6rvSQ3kV9KZi/zNICu4ofA7/XaNY5zMZGYrj4wpjSEq3xY6JR shNQZ8ajWzM= =N7uT -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Sun Mar 10 19:06:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2B36Ov16175 for netdev-outgoing; Sun, 10 Mar 2002 19:06:24 -0800 Received: from nori.vegan.net (IDENT:root@[198.143.3.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2B36I916172 for ; Sun, 10 Mar 2002 19:06:19 -0800 Received: from localhost (tony@localhost) by nori.vegan.net (8.11.0/8.11.0) with ESMTP id g2B26OU29626 for ; Sun, 10 Mar 2002 21:06:24 -0500 Date: Sun, 10 Mar 2002 21:06:24 -0500 (EST) From: tony bourke To: Subject: tcpPassiveOpens Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 682 Lines: 28 Hello, Sami Farin recommended I bring this up with this list. I was doing research into performance metrics when I noticed that tcpPassiveOpens counter wasn't being incremented. tcp.tcpActiveOpens.0 = Counter32: 102942 tcp.tcpPassiveOpens.0 = Counter32: 0 Upon investigation, I saw an email on a list, an exchange between Sami and Alan Cox: http://www.uwsg.iu.edu/hypermail/linux/net/9909.1/0151.html Is it possible to include the tcpPassiveOpens counter? For keeping track of performance metrics, tcpPassiveOpens can be quite valuable. Thank you for your time, Tony -- -------------- -- ---- ---- --- - - - - - -- - - - - - - Tony Bourke tony@vegan.net From owner-netdev@oss.sgi.com Sun Mar 10 21:29:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2B5TqU21985 for netdev-outgoing; Sun, 10 Mar 2002 21:29:52 -0800 Received: from grok.yi.org (ip68-3-107-226.ph.ph.cox.net [68.3.107.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2B5Tj921982 for ; Sun, 10 Mar 2002 21:29:46 -0800 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g2B4TWO22416; Sun, 10 Mar 2002 21:29:32 -0700 Message-ID: <3C8C32AC.7070104@candelatech.com> Date: Sun, 10 Mar 2002 21:29:32 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "David S. Miller" CC: jgarzik@mandrakesoft.com, akpm@zip.com.au, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BK PATCHES] lotsa net driver merges References: <3C8746EC.CA7B0295@mandrakesoft.com> <3C879692.8010103@candelatech.com> <3C87CB5C.61703012@mandrakesoft.com> <20020309.154914.121220659.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1743 Lines: 48 David S. Miller wrote: > From: Jeff Garzik > Date: Thu, 07 Mar 2002 15:19:40 -0500 > > Ben Greear wrote: > > In case you are using intel's 1.8.37 driver, I can cause a kernel panic > > in it by trying to reset the transceiver through MII IOCTLs.. I've > > been passing email with their support, so hopefully it will be resolved > > soon. > ... > Anyway, this is e100 version 2.0.19, with lots of changes by the Intel > folks at my request. > > Ben, I'm going to put your report in the same classification > as "root cat'd crap into /dev/kmem and the kernel crashed". > > If you are programming the PHY directly with MII IOCTLs you are on > your own. I personally refuse to monitor how the user pokes at the > MII in my drivers to try and cope with the user putting the PHY into a > weird state that the driver would otherwise never need to deal with. > > It is not a bug, pure and simple. It crashed my kernel, and no other driver has done that yet, so I consider it a bug. The reason I tried the MII ioctl was because the chip was locked up (couldn't receive packets), so the MII crash may be a symptom of the first. At any rate, the driver I was testing from Intel's site was not stable. I have yet to try the e100 that Jeff sent out, but his later email made it sound pretty experimental. I'll look forward to poking at it when it goes into the 2.4 series, but if using the MII interface makes it unstable, I will not be able to use it. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Mon Mar 11 11:11:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BJBQM08866 for netdev-outgoing; Mon, 11 Mar 2002 11:11:26 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BJBM908863 for ; Mon, 11 Mar 2002 11:11:22 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA24266; Mon, 11 Mar 2002 21:11:05 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200203111811.VAA24266@ms2.inr.ac.ru> Subject: Re: addrconf.c - possible bug To: pekkas@netcore.fi (Pekka Savola) Date: Mon, 11 Mar 2002 21:11:05 +0300 (MSK) Cc: jan.oravec@xs26.net, netdev@oss.sgi.com, xs26-dev@xs26.net In-Reply-To: from "Pekka Savola" at Mar 10, 2 08:27:38 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 730 Lines: 21 Hello! > I think I've seen something similar to this before, and IIRC it was caused > by the fact that loopback interface had been brought down. I feel this is 100% precise diahnosis. > If loopback has been taken down and is back up, IIRC the addresses of the > interfaces must be "refreshed" (e.g. by also taking the interfaces down > and up). Pekka, is it worth to graft local addresses back when loopback goes up? Actually, this is too easy and will stop the confusion, at least when loopback is not held down forever. Argh, I believed that after several years of 2.2 generating funny messages when loopback is down, all the people undertood that downing loopback means death of network. This was mistake. :-) Alexey From owner-netdev@oss.sgi.com Mon Mar 11 11:15:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BJF7Q08989 for netdev-outgoing; Mon, 11 Mar 2002 11:15:07 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BJF2908984 for ; Mon, 11 Mar 2002 11:15:02 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2BIEql16668; Mon, 11 Mar 2002 20:14:52 +0200 Date: Mon, 11 Mar 2002 20:14:52 +0200 (EET) From: Pekka Savola To: kuznet@ms2.inr.ac.ru cc: jan.oravec@xs26.net, , Subject: Re: addrconf.c - possible bug In-Reply-To: <200203111811.VAA24266@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1002 Lines: 24 On Mon, 11 Mar 2002 kuznet@ms2.inr.ac.ru wrote: > > I think I've seen something similar to this before, and IIRC it was caused > > by the fact that loopback interface had been brought down. > > I feel this is 100% precise diahnosis. > > > > If loopback has been taken down and is back up, IIRC the addresses of the > > interfaces must be "refreshed" (e.g. by also taking the interfaces down > > and up). > > Pekka, is it worth to graft local addresses back when loopback goes up? > Actually, this is too easy and will stop the confusion, at least when > loopback is not held down forever. I think this seems feasible and should be done; if IPv4 and IPv6 worked in a similar fashion wrt. this, the current behaviour might be more understandable, but currently it'll just generate confusion. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Mon Mar 11 11:17:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BJHNw09117 for netdev-outgoing; Mon, 11 Mar 2002 11:17:23 -0800 Received: from shell.cyberus.ca (shell.cyberus.ca [216.191.240.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BJHL909114 for ; Mon, 11 Mar 2002 11:17:21 -0800 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id NAA27174; Mon, 11 Mar 2002 13:12:17 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 11 Mar 2002 13:12:17 -0500 (EST) From: jamal To: Matti Aarnio cc: Chris Wedgwood , Subject: Re: ipv4.o module In-Reply-To: <20020310042603.H10704@mea-ext.zmailer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 257 Lines: 13 Folks, Have you thought of the pandora box this opens? Imagine someone running a BSD IP module to replace the Linux one (and of course many proprietary others). The question is more philosophical than technical: Is this a Good Thing(tm)? cheers, jamal From owner-netdev@oss.sgi.com Mon Mar 11 11:37:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BJba509451 for netdev-outgoing; Mon, 11 Mar 2002 11:37:36 -0800 Received: from grok.yi.org (ip68-3-107-226.ph.ph.cox.net [68.3.107.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BJbV909448 for ; Mon, 11 Mar 2002 11:37:31 -0800 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g2BIbOO28731; Mon, 11 Mar 2002 11:37:24 -0700 Message-ID: <3C8CF964.3020202@candelatech.com> Date: Mon, 11 Mar 2002 11:37:24 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: jamal CC: Matti Aarnio , Chris Wedgwood , netdev@oss.sgi.com Subject: Re: ipv4.o module References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 875 Lines: 35 jamal wrote: > > Folks, > > Have you thought of the pandora box this opens? > Imagine someone running a BSD IP module to replace the > Linux one (and of course many proprietary others). > The question is more philosophical than technical: Is this a Good > Thing(tm)? It does not bother me, it seems no worse than using/allowing a proprietary ethernet driver. If by some chance someone makes a better IP stack and plugs it in, it might provide some useful competition. If the licensing politics are too much for some people to handle, then you can create a GPL-only symbol that must be exported, or some hack like that. > > cheers, > jamal > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Mon Mar 11 11:41:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BJfQf09556 for netdev-outgoing; Mon, 11 Mar 2002 11:41:26 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BJfN909553 for ; Mon, 11 Mar 2002 11:41:23 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g2BIfFC09739 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 11 Mar 2002 13:41:17 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g2BIfCt00693; Mon, 11 Mar 2002 13:41:15 -0500 (EST) Message-Id: <200203111841.g2BIfCt00693@marajade.sandelman.ottawa.on.ca> To: jamal cc: Matti Aarnio , Chris Wedgwood , netdev@oss.sgi.com Subject: Re: ipv4.o module In-reply-to: Your message of "Mon, 11 Mar 2002 13:12:17 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Mar 2002 13:41:11 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 925 Lines: 20 >>>>> "jamal" == jamal writes: jamal> Have you thought of the pandora box this opens? jamal> Imagine someone running a BSD IP module to replace the jamal> Linux one (and of course many proprietary others). Or, running the Linux one on BSD :-) jamal> The question is more philosophical than technical: Is this a Good jamal> Thing(tm)? I think it would be very useful for people building very small systems to be able to load only UDP/IP or UDP/IPv6+IPsec or something.... e.g. for a water meter. and to do this from secondary flash instead of primary boot. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-netdev@oss.sgi.com Mon Mar 11 11:52:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BJqY309745 for netdev-outgoing; Mon, 11 Mar 2002 11:52:34 -0800 Received: from angateway.acceleratednetworks.com ([12.44.127.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BJqW909741 for ; Mon, 11 Mar 2002 11:52:32 -0800 Received: from CALVIN.acceleratednetworks.com (calvin.acceleratednetworks.com [199.107.109.14]) by angateway.acceleratednetworks.com (8.8.8/8.8.8) with ESMTP id KAA09200 for ; Mon, 11 Mar 2002 10:42:44 -0800 (PST) Received: by CALVIN.acceleratednetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 10:47:02 -0800 Message-ID: <8B57A2E9423E844C911DF3BC5DB06E500FA0F5@CALVIN.acceleratednetworks.com> From: Shridhar Kulkarni To: "'netdev@oss.sgi.com'" Subject: CONFIG_ARPD Date: Mon, 11 Mar 2002 10:46:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 96 Lines: 4 Does anybody know if RedHat 2.4.7-10 kernel is compiled with CONFIG_ARPD flag ????? thanx Shri. From owner-netdev@oss.sgi.com Mon Mar 11 12:04:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BK42t10160 for netdev-outgoing; Mon, 11 Mar 2002 12:04:02 -0800 Received: from cogenit.fr (se1.cogenit.fr [195.68.53.173]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BK3x910157 for ; Mon, 11 Mar 2002 12:03:59 -0800 Received: from se1.cogenit.fr (localhost [127.0.0.1]) by cogenit.fr (8.12.1/8.12.1) with ESMTP id g2BJ3ulU009950 for ; Mon, 11 Mar 2002 20:03:56 +0100 Received: (from romieu@localhost) by se1.cogenit.fr (8.12.1/8.12.1) id g2BJ3umG009949 for netdev@oss.sgi.com; Mon, 11 Mar 2002 20:03:56 +0100 Date: Mon, 11 Mar 2002 20:03:56 +0100 From: Francois Romieu To: netdev@oss.sgi.com Subject: Re: ipv4.o module Message-ID: <20020311200356.A9208@se1.cogenit.fr> References: <20020310042603.H10704@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hadi@cyberus.ca on Mon, Mar 11, 2002 at 01:12:17PM -0500 X-Organisation: Marie's fan club - II Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 445 Lines: 14 (Cc trimmed, everybody is here) jamal : > Have you thought of the pandora box this opens? > Imagine someone running a BSD IP module to replace the > Linux one (and of course many proprietary others). > The question is more philosophical than technical: Is this a Good > Thing(tm)? Isn't it simpler to completely use BSD for proprietary application and avoid any hassle with "derived work" subject to GPL then ? -- Ueimor From owner-netdev@oss.sgi.com Mon Mar 11 14:46:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BMkUD15144 for netdev-outgoing; Mon, 11 Mar 2002 14:46:30 -0800 Received: from zmailer.org ([195.163.186.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BMkQ915141 for ; Mon, 11 Mar 2002 14:46:27 -0800 Received: (mea@mea-ext) by mail.zmailer.org id ; Mon, 11 Mar 2002 23:46:15 +0200 Date: Mon, 11 Mar 2002 23:46:15 +0200 From: Matti Aarnio To: jamal Cc: Matti Aarnio , Chris Wedgwood , netdev@oss.sgi.com Subject: Re: ipv4.o module Message-ID: <20020311234615.B27741@mea-ext.zmailer.org> References: <20020310042603.H10704@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from hadi@cyberus.ca on Mon, Mar 11, 2002 at 01:12:17PM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 486 Lines: 19 On Mon, Mar 11, 2002 at 01:12:17PM -0500, jamal wrote: > Folks, > > Have you thought of the pandora box this opens? Nothing new. > Imagine someone running a BSD IP module to replace the > Linux one (and of course many proprietary others). > The question is more philosophical than technical: > Is this a Good Thing(tm)? You can do that already. You just DON'T define CONFIG_INET, and you will have room for plugging in your own IPv4 stack. > cheers, > jamal /Matti Aarnio From owner-netdev@oss.sgi.com Mon Mar 11 17:22:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C1Msk19180 for netdev-outgoing; Mon, 11 Mar 2002 17:22:54 -0800 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C1MW919174 for ; Mon, 11 Mar 2002 17:22:32 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.52 2002/03/01 19:20:46 root Exp $) with SMTP id AAA08526 for ; Tue, 12 Mar 2002 00:22:32 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031116254725276 for ; Mon, 11 Mar 2002 16:25:47 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 16:22:32 -0800 Message-ID: From: "Hossain, Mohammad" To: netdev@oss.sgi.com Subject: What is wrong here????? Date: Mon, 11 Mar 2002 16:22:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4744 Lines: 197 Hello, Thanks for your valuable time. I appreciate. Here is one IPv4 raw client and server code. When I run them, I get nothing in the server. Would you pls help me out, what is wrong here??? This code will compile without warning. I will wait for your reply. Arif. /* -------------------------- client code ------------------------------ */ / * solaris compile : >gcc -D_XPG4_2 -o clt raw4Client.c -lnsl -lsocket * run : >sudo ./clt */ #include #include #include #include #include #include #include #include #include #include #include #define SERVERPORT 9000 /* the port users will be connecting to */ int main(int argc, char *argv[]) { int sockfd; struct sockaddr_in server_addr; struct sockaddr_in client_addr; struct hostent *he; int nbytes; int i=0; int SOCK_OPT_ENABLE; char *buf ="Hello There .... \0"; struct iovec io[1]; struct msghdr msg; struct msghdr msgRecv; struct iovec ioRecv[1]; char recvBuf[100]; SOCK_OPT_ENABLE = 1; if (argc != 2) he=gethostbyname("nsdla03.trillium.com"); else { if ((he=gethostbyname(argv[1])) == NULL) { perror("gethostbyname"); exit(1); } } if ((sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) == -1) { perror("socket"); exit(1); } /* reuseaddr sock opt */ setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &SOCK_OPT_ENABLE, sizeof(SOCK_OPT_ENABLE)); /* fill up client info */ client_addr.sin_family=AF_INET; client_addr.sin_port=htons(9001); client_addr.sin_addr.s_addr=htonl(INADDR_ANY); bzero(&(client_addr.sin_zero),8); /* No need to bind client raw socket */ /* fill up server address info */ server_addr.sin_family = AF_INET; server_addr.sin_port = htons(SERVERPORT); server_addr.sin_addr = *((struct in_addr *)he->h_addr); bzero(&(server_addr.sin_zero),8); /* fill up sending msghdr structure */ memset(&msg, 0, sizeof(struct msghdr)); io[0].iov_base = buf; io[0].iov_len = strlen(buf); msg.msg_name = &server_addr; msg.msg_namelen = sizeof(struct sockaddr); msg.msg_iov = io; msg.msg_iovlen = 1; msg.msg_control = NULL; msg.msg_controllen = 0; msg.msg_flags = 0; /* send 5 data packets */ for(i=0; i < 5; i++) { nbytes = sendmsg(sockfd, &msg, 0); printf("%d bytes sent\n", nbytes); if(nbytes == -1) { perror("sendmsg()"); printf("Error #: %d\n", errno); exit(1); } sleep(1); } close(sockfd); return 0; } /* -------------------------- server code ------------------------------ */ /* * solaris compile : >gcc -D_XPG4_2 -o svr raw4Server.c -lnsl -lsocket * solaris run : >sudo ./svr */ #include #include #include #include #include #include #include #include #include #include #include #define MYPORT 9000 /* port doesn't mean anything in raw socket! */ int main(void) { int sockfd; struct sockaddr_in server_addr; struct sockaddr_in client_addr; int nbytes = 0; struct msghdr msgRecv; struct iovec recvIovec[1]; char buf[100]; /* create the UDP socket */ if ((sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) == -1) { perror("socket"); exit(1); } /* bind the UDP socket of server with local port */ memset(&server_addr, 0, sizeof(struct sockaddr_in)); server_addr.sin_family=AF_INET; server_addr.sin_port=htons(MYPORT); server_addr.sin_addr.s_addr=htonl(INADDR_ANY); bzero(&(server_addr.sin_zero),8); /* binding */ /* No Need to Bind RAW server !! */ printf("\n raw server waiting for data.....\n"); while(1) { /* fill up receiving msghdr structure */ memset(&msgRecv, 0, sizeof(struct msghdr)); recvIovec[0].iov_base = buf; recvIovec[0].iov_len = strlen(buf); msgRecv.msg_name = &client_addr; msgRecv.msg_namelen = sizeof(client_addr); msgRecv.msg_iov = recvIovec; msgRecv.msg_iovlen = 1; msgRecv.msg_control = NULL; msgRecv.msg_controllen = 0; msgRecv.msg_flags = 0; /* receive data */ if(nbytes = recvmsg(sockfd, &msgRecv, 0) == -1) { perror("recvmsg"); printf("Error #: %d\n", errno); exit(1); } /* print recvd data info*/ printf("received = % bytes\n", nbytes); printf("%s\n", (char *)recvIovec[0].iov_base); nbytes = 0; } close(sockfd); return 0; } From owner-netdev@oss.sgi.com Tue Mar 12 12:08:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CK8pb19067 for netdev-outgoing; Tue, 12 Mar 2002 12:08:51 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CK8i918761 for ; Tue, 12 Mar 2002 12:08:45 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2CJ8bd27720 for ; Tue, 12 Mar 2002 21:08:38 +0200 Date: Tue, 12 Mar 2002 21:08:37 +0200 (EET) From: Pekka Savola To: netdev@oss.sgi.com Subject: Deadlock problem with TCP v6? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2468 Lines: 44 Hello, There appears to be some weird problem with TCP over IPv6 with 2.4.18. At least with RHL72 kernel (2.4.9-xx), this does not happen. The topology is such: 2001:708:10:10:250:4ff:fe6a:db55 - Linux client 2001:708:10:f::c1a6:45 - FreeBSD 4.5 TCP relay (using IPv6-to-IPv4 relay) The test is done with basically 'lynx [http://[2001:708:10:f::c1a6:45]', the same also happens if telnetting to port 80 and issuing 'GET / HTTP/1.0' The problem is that FreeBSD never seems to be able to send the data it receives from IPv4 to the Linux client: netstat -an shows the data is kept in SendQ of the connection, which is CLOSING state. Linux client never sees the data. Works: - Linux 2.4.9 (at least) works (the same system) - Linux 2.4.9, 2.4.12, 2.4.18 and other versions do work from some other topological locations: it seems that this happens only if the latency between the boxes is very low. Perhaps some TCP specilist can shed some light on this? 17:12:51.254612 2001:708:10:10:250:4ff:fe6a:db55.1046 > 2001:708:10:f::c1a6:45.http: S [tcp sum ok] 3514706145:3514706145(0) win 5760 (len 40, hlim 64) 17:12:51.259395 2001:708:10:f::c1a6:45.http > 2001:708:10:10:250:4ff:fe6a:db55.1046: S [tcp sum ok] 2663223199:2663223199(0) ack 3514706146 win 65535 (len 40, hlim 61) 17:12:51.259457 2001:708:10:10:250:4ff:fe6a:db55.1046 > 2001:708:10:f::c1a6:45.http: . [tcp sum ok] 1:1(0) ack 1 win 5760 (len 32, hlim 64) 17:12:51.260802 2001:708:10:10:250:4ff:fe6a:db55.1046 > 2001:708:10:f::c1a6:45.http: P 1:537(536) ack 1 win 5760 (len 568, hlim 64) 17:12:51.468662 2001:708:10:10:250:4ff:fe6a:db55.1046 > 2001:708:10:f::c1a6:45.http: P 1:537(536) ack 1 win 5760 (len 568, hlim 64) 17:12:51.474158 2001:708:10:f::c1a6:45.http > 2001:708:10:10:250:4ff:fe6a:db55.1046: . [tcp sum ok] 2857:2857(0) ack 537 win 32844 [flowlabel 0x60695] (len 32, hlim 61) Any thoughts? Does this appear to be a FreeBSD or Linux problem? (I'd be tempted to say Linux, because it works in some versions but not others.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Tue Mar 12 20:01:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2D41G730240 for netdev-outgoing; Tue, 12 Mar 2002 20:01:16 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2D41B930237 for ; Tue, 12 Mar 2002 20:01:11 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g2D30qL01584 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 12 Mar 2002 22:01:03 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g2D01ip00466; Tue, 12 Mar 2002 19:01:47 -0500 (EST) Message-Id: <200203130001.g2D01ip00466@marajade.sandelman.ottawa.on.ca> To: Pekka Savola cc: netdev@oss.sgi.com Subject: Re: Deadlock problem with TCP v6? In-reply-to: Your message of "Tue, 12 Mar 2002 21:08:37 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 12 Mar 2002 19:01:44 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1639 Lines: 40 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Savola writes: Pekka> There appears to be some weird problem with TCP over IPv6 with 2.4.18. Pekka> At least with RHL72 kernel (2.4.9-xx), this does not happen. Pekka> The topology is such: Pekka> 2001:708:10:10:250:4ff:fe6a:db55 - Linux client Pekka> 2001:708:10:f::c1a6:45 - FreeBSD 4.5 TCP relay (using IPv6-to-IPv4 relay) Pekka> The test is done with basically 'lynx [http://[2001:708:10:f::c1a6:45]', Pekka> the same also happens if telnetting to port 80 and issuing 'GET / Pekka> HTTP/1.0' Pekka> The problem is that FreeBSD never seems to be able to send the data it Pekka> receives from IPv4 to the Linux client: netstat -an shows the data is kept Pekka> in SendQ of the connection, which is CLOSING state. Linux client never Pekka> sees the data. You mean you are hitting the FreeBSD box directly, so what has 6to4 got to do with it? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPI6W5YqHRg3pndX9AQEelgP/Qccu+THI9nO6vqlEHgEs+DeQMvb7+k7h 2CdwSUjP2penJ23AW1Yt+BAPWUvjs0swywbS0PzKvle+xOw3eYkpSoiPdkAaTzTS lM9nI0msYwMd+XCI6eXsmpM9dopgrdMg8WX1SDT6pKORzB64p/bzmVI7zpZk2xhA QCJXV5ISCZk= =IUUf -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Wed Mar 13 00:45:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2D8jbW02273 for netdev-outgoing; Wed, 13 Mar 2002 00:45:37 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2D8jW902269 for ; Wed, 13 Mar 2002 00:45:32 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2D7jFQ00736; Wed, 13 Mar 2002 09:45:16 +0200 Date: Wed, 13 Mar 2002 09:45:15 +0200 (EET) From: Pekka Savola To: Michael Richardson cc: netdev@oss.sgi.com Subject: Re: Deadlock problem with TCP v6? In-Reply-To: <200203130001.g2D01ip00466@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1533 Lines: 35 On Tue, 12 Mar 2002, Michael Richardson wrote: > >>>>> "Pekka" == Pekka Savola writes: > Pekka> There appears to be some weird problem with TCP over IPv6 with 2.4.18. > Pekka> At least with RHL72 kernel (2.4.9-xx), this does not happen. > > Pekka> The topology is such: > > Pekka> 2001:708:10:10:250:4ff:fe6a:db55 - Linux client > Pekka> 2001:708:10:f::c1a6:45 - FreeBSD 4.5 TCP relay (using IPv6-to-IPv4 relay) > > Pekka> The test is done with basically 'lynx [http://[2001:708:10:f::c1a6:45]', > Pekka> the same also happens if telnetting to port 80 and issuing 'GET / > Pekka> HTTP/1.0' > > Pekka> The problem is that FreeBSD never seems to be able to send the data it > Pekka> receives from IPv4 to the Linux client: netstat -an shows the data is kept > Pekka> in SendQ of the connection, which is CLOSING state. Linux client never > Pekka> sees the data. > > You mean you are hitting the FreeBSD box directly, so what has 6to4 got to > do with it? Well, to be exact, "IPv6-to-IPv4" not "6to4" (RFC3056). Yes, I'm connecting to the FreeBSD box directly. I said the above just for completeness, as it _might_ also be a bug in faithd/faith. I guess until some ideas surface, I'll forward this to KAME lists, and see if they have any ideas. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Wed Mar 13 13:16:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2DLGpP26271 for netdev-outgoing; Wed, 13 Mar 2002 13:16:51 -0800 Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2DLGV926258 for ; Wed, 13 Mar 2002 13:16:31 -0800 Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.52 2002/03/01 19:20:46 root Exp $) with SMTP id UAA10032 for ; Wed, 13 Mar 2002 20:16:23 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031312222124166 for ; Wed, 13 Mar 2002 12:22:21 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 12:16:23 -0800 Message-ID: From: "Hossain, Mohammad" To: netdev@oss.sgi.com Subject: Would pls help me? Date: Wed, 13 Mar 2002 12:16:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4407 Lines: 168 Hello, I need your help if you have Linux IPv6 Raw support on your machine. I am getting "Invalid Argument" on my IPv6 Linux (RedHat 7.2 Kernel 2.4.7) machine when I am opening and sending data through Raw socket. But this same code works fine with UDP ipv6. It may be configuration problem in my machine OR it may be a bug in my code. I really don't know. To find it out I need your help. Would you please compile and run the following code on your machine and tell me the result. Thanks for your time and support. Arif ----------------------------------------------------test.c------------------ ----------------------------------- /* * Linux: * compile - >gcc -o cltsvr test.c -lnsl * run - >sudo ./cltsvr */ #include #include #include #include #include #include /*for select() */ #include #include #define BUFSIZE 100 void raw6SendRecv() { struct sockaddr_in6 addr6; int size, sd, enable = 1, i; struct msghdr msg; struct iovec io; char sendbuf[BUFSIZE]; /* variables for receiving data */ struct sockaddr_in6 remSockAddr6; struct msghdr msgRecv; struct iovec ioRecv; char recvbuf[BUFSIZE]; int recvLen = 0; /* for select() */ fd_set rFdSet; struct timeval selTime; int num; sd = socket(AF_INET6, SOCK_RAW, 132); /* 132 for SCTP, 46 for RSVP */ printf("sd is %d\n",sd); if(sd == -1) { perror("socket()"); exit(1); } if(ioctl(sd, FIONBIO, &enable) == -1) { perror("ioctl()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_BSDCOMPAT, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } if(setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(enable)) == -1) { perror("setsockopt()"); exit(1); } memset(&addr6, 0, sizeof(addr6)); size = sizeof(struct sockaddr_in6); addr6.sin6_family = AF_INET6; addr6.sin6_port = htons(4200); memcpy(&addr6.sin6_addr, &in6addr_loopback, sizeof(struct in6_addr)); if(bind(sd, (struct sockaddr *)&addr6, size) == -1) { perror("bind()"); exit(1); } sprintf(sendbuf, "This data is sent to this socket itself\n"); io.iov_base = sendbuf; io.iov_len = BUFSIZE; printf("sendbuf=%s\n", io.iov_base); msg.msg_name = &addr6; msg.msg_namelen = sizeof(struct sockaddr_in6); msg.msg_iov = &io; msg.msg_iovlen = 1; msg.msg_control = NULL; msg.msg_controllen = 0; msg.msg_flags = 0; i = sendmsg(sd, &msg, 0); printf("%d bytes sent\n", i); if(i == -1) { perror("sendmsg()"); exit(1); } /* receiving Raw IPv6 Data */ FD_ZERO(&rFdSet); FD_SET(sd, &rFdSet); selTime.tv_sec = 20; /* select will wait 20 sec for data */ selTime.tv_usec = 0; num = select(sd+1, &rFdSet, NULL, NULL, &selTime); if(num <= 0) printf("No data arrived as no socket is set by select!\n"); else if FD_ISSET(sd, &rFdSet) { memset(&remSockAddr6, 0, sizeof(remSockAddr6)); memset(&msgRecv, 0, sizeof(msgRecv)); ioRecv.iov_base = recvbuf; ioRecv.iov_len = BUFSIZE; msgRecv.msg_name = (void *)&remSockAddr6; msgRecv.msg_namelen = sizeof(remSockAddr6); msgRecv.msg_control = NULL; msgRecv.msg_controllen = 0; msgRecv.msg_iov = &ioRecv; msgRecv.msg_iovlen = 1; msgRecv.msg_flags = 0; recvLen = recvmsg(sd, &msgRecv, 0); printf("%d bytes recvd\n",recvLen); printf("Port is=%d\n", ntohs(remSockAddr6.sin6_port)); //printf("Remote addr is=%s\n", remSockAddr6.sin6_addr); printf("recvbuf=%s\n", recvbuf); if((errno==EBADF)||(errno==ECONNREFUSED)||(errno==ENOTCONN)|| (errno==ENOTSOCK)||(errno== EAGAIN)||(errno==EINTR)|| (errno==EFAULT)||(errno==EINVAL)) { printf("One of these error\n"); printf("error no: %d\n",errno); } } } int main(void) { /* variables for opening socket & sending data */ raw6SendRecv(); exit(0); } From owner-netdev@oss.sgi.com Wed Mar 13 15:39:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2DNdI606239 for netdev-outgoing; Wed, 13 Mar 2002 15:39:18 -0800 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2DNcw906229 for ; Wed, 13 Mar 2002 15:38:58 -0800 Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.52 2002/03/01 19:20:46 root Exp $) with SMTP id WAA18635 for ; Wed, 13 Mar 2002 22:38:53 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031314445100816 for ; Wed, 13 Mar 2002 14:44:51 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 14:38:53 -0800 Message-ID: From: "Hossain, Mohammad" To: "'netdev@oss.sgi.com'" Subject: RE: Would pls help me? Date: Wed, 13 Mar 2002 14:38:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4945 Lines: 178 Thanks. I found the problem myself!!!! > -----Original Message----- > From: Hossain, Mohammad > Sent: Wednesday, March 13, 2002 12:16 PM > To: netdev@oss.sgi.com > Subject: Would pls help me? > > Hello, > I need your help if you have Linux IPv6 Raw support on your machine. I > am getting "Invalid Argument" on my IPv6 Linux (RedHat 7.2 Kernel 2.4.7) > machine when I am opening and sending data through Raw socket. But this > same code works fine with UDP ipv6. It may be configuration problem in my > machine OR it may be a bug in my code. I really don't know. To find it out > I need your help. > > Would you please compile and run the following code on your machine and > tell me the result. > > Thanks for your time and support. > > Arif > > ----------------------------------------------------test.c---------------- > ------------------------------------- > /* > * Linux: > * compile - >gcc -o cltsvr test.c -lnsl > * run - >sudo ./cltsvr > */ > > > #include > #include > #include > #include > #include > #include > > /*for select() */ > #include > #include > #define BUFSIZE 100 > void raw6SendRecv() > { > struct sockaddr_in6 addr6; > int size, sd, enable = 1, i; > struct msghdr msg; > struct iovec io; > char sendbuf[BUFSIZE]; > > /* variables for receiving data */ > struct sockaddr_in6 remSockAddr6; > struct msghdr msgRecv; > struct iovec ioRecv; > char recvbuf[BUFSIZE]; > int recvLen = 0; > > /* for select() */ > fd_set rFdSet; > struct timeval selTime; > int num; > > sd = socket(AF_INET6, SOCK_RAW, 132); /* 132 for SCTP, 46 > for RSVP */ > printf("sd is %d\n",sd); > if(sd == -1) > { > perror("socket()"); exit(1); > } > > if(ioctl(sd, FIONBIO, &enable) == -1) > { > perror("ioctl()"); exit(1); > } > > if(setsockopt(sd, SOL_SOCKET, SO_BSDCOMPAT, &enable, > sizeof(enable)) == -1) > { > perror("setsockopt()"); > exit(1); > } > > if(setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &enable, > sizeof(enable)) == -1) > { > perror("setsockopt()"); > exit(1); > } > > memset(&addr6, 0, sizeof(addr6)); > size = sizeof(struct sockaddr_in6); > addr6.sin6_family = AF_INET6; > addr6.sin6_port = htons(4200); > memcpy(&addr6.sin6_addr, &in6addr_loopback, sizeof(struct > in6_addr)); > if(bind(sd, (struct sockaddr *)&addr6, size) == -1) > { > perror("bind()"); exit(1); > } > > sprintf(sendbuf, "This data is sent to this socket > itself\n"); > io.iov_base = sendbuf; io.iov_len = BUFSIZE; > printf("sendbuf=%s\n", io.iov_base); > msg.msg_name = &addr6; msg.msg_namelen = sizeof(struct > sockaddr_in6); > msg.msg_iov = &io; msg.msg_iovlen = 1; > msg.msg_control = NULL; msg.msg_controllen = 0; > msg.msg_flags = 0; > i = sendmsg(sd, &msg, 0); > printf("%d bytes sent\n", i); > > if(i == -1) > { > perror("sendmsg()"); > exit(1); > } > > /* receiving Raw IPv6 Data */ > FD_ZERO(&rFdSet); > FD_SET(sd, &rFdSet); > selTime.tv_sec = 20; /* select will wait 20 sec for data > */ > selTime.tv_usec = 0; > > num = select(sd+1, &rFdSet, NULL, NULL, &selTime); > if(num <= 0) > printf("No data arrived as no socket is set by > select!\n"); > else if FD_ISSET(sd, &rFdSet) > { > memset(&remSockAddr6, 0, sizeof(remSockAddr6)); > > memset(&msgRecv, 0, sizeof(msgRecv)); > > ioRecv.iov_base = recvbuf; > ioRecv.iov_len = BUFSIZE; > > msgRecv.msg_name = (void *)&remSockAddr6; > msgRecv.msg_namelen = sizeof(remSockAddr6); > msgRecv.msg_control = NULL; > msgRecv.msg_controllen = 0; > msgRecv.msg_iov = &ioRecv; > msgRecv.msg_iovlen = 1; > msgRecv.msg_flags = 0; > > recvLen = recvmsg(sd, &msgRecv, 0); > > printf("%d bytes recvd\n",recvLen); > > printf("Port is=%d\n", ntohs(remSockAddr6.sin6_port)); > //printf("Remote addr is=%s\n", > remSockAddr6.sin6_addr); > > printf("recvbuf=%s\n", recvbuf); > > > if((errno==EBADF)||(errno==ECONNREFUSED)||(errno==ENOTCONN)|| > (errno==ENOTSOCK)||(errno== > EAGAIN)||(errno==EINTR)|| > (errno==EFAULT)||(errno==EINVAL)) > { > printf("One of these error\n"); > printf("error no: %d\n",errno); > } > } > > } > int main(void) { > /* variables for opening socket & sending data */ > raw6SendRecv(); > exit(0); > } > > From owner-netdev@oss.sgi.com Wed Mar 13 16:21:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E0LOL20632 for netdev-outgoing; Wed, 13 Mar 2002 16:21:24 -0800 Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2E0LL920629 for ; Wed, 13 Mar 2002 16:21:21 -0800 Received: from DOCOMOHE (dhcp50.docomolabs-usa.com [172.21.96.50]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with ESMTP id g2E0MjI11694 for ; Wed, 13 Mar 2002 16:22:45 -0800 (PST) From: "Xiaoning He" To: Subject: Kernel Memory Functions Date: Wed, 13 Mar 2002 16:23:44 -0800 Organization: NTT-Docomo USA Lab Message-ID: <000601c1caee$805277c0$326015ac@DOCOMOHE> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 446 Lines: 17 Hi all I am trying to modify the kernel. I need some memory operations including memset, memcpy, malloc etc. I was told that these functions are not available in the kernel namespace, and I have to use some different functions like kmalloc() etc. However, I can not find the information about how to use these functions. Could you please let me know where I can find the information about how to use these functions? Thank you Xiaoning He From owner-netdev@oss.sgi.com Wed Mar 13 18:37:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E2bIo22720 for netdev-outgoing; Wed, 13 Mar 2002 18:37:18 -0800 Received: from yue.hongo.wide.ad.jp (root@yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2E2bG922714 for ; Wed, 13 Mar 2002 18:37:16 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id LAA19971; Thu, 14 Mar 2002 11:38:27 +0900 To: m_hossain@trillium.com Cc: netdev@oss.sgi.com Subject: Re: Would pls help me? In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020314113827P.yoshfuji@wide.ad.jp> Date: Thu, 14 Mar 2002 11:38:27 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 699 Lines: 13 In article (at Wed, 13 Mar 2002 12:16:01 -0800), "Hossain, Mohammad" says: > I need your help if you have Linux IPv6 Raw support on your machine. I am > getting "Invalid Argument" on my IPv6 Linux (RedHat 7.2 Kernel 2.4.7) > machine when I am opening and sending data through Raw socket. But this same > code works fine with UDP ipv6. It may be configuration problem in my machine > OR it may be a bug in my code. I really don't know. To find it out I need > your help. You should not set sin6_port other than zero (or the protocol number you've specified on socket creation) for raw sockets. --yoshfuji From owner-netdev@oss.sgi.com Wed Mar 13 18:46:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E2knc22959 for netdev-outgoing; Wed, 13 Mar 2002 18:46:49 -0800 Received: from web13002.mail.yahoo.com (web13002.mail.yahoo.com [216.136.174.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2E2kk922953 for ; Wed, 13 Mar 2002 18:46:46 -0800 Message-ID: <20020314024815.63965.qmail@web13002.mail.yahoo.com> Received: from [65.209.235.11] by web13002.mail.yahoo.com via HTTP; Wed, 13 Mar 2002 18:48:15 PST Date: Wed, 13 Mar 2002 18:48:15 -0800 (PST) From: Yan-Fa Li Subject: Loopback Bug ? To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 710 Lines: 22 Hi, I have a strange problem with 2.4.14. I have a client and server application where the server is bound in INADDR_ANY of a TCP port. It accepts connections off multiple network interfaces. However it also needs to receive connections via Loopback. Here's the problem, if we physically disconnect the interface which happens to be our default gateway, connections to the server via loopback begin to fail. If we bring the interface down administratively using ifconfig, then the connections to the server via loopback work again. Is this the correct behavior ? Yan __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ From owner-netdev@oss.sgi.com Wed Mar 13 22:08:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E68Tv26505 for netdev-outgoing; Wed, 13 Mar 2002 22:08:29 -0800 Received: from mail.osdl.org (air-2.osdl.org [65.201.151.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2E68M926500 for ; Wed, 13 Mar 2002 22:08:23 -0800 Received: from osdlab.pdx.osdl.net (osdlab.pdx.osdl.net [172.20.1.28]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id g2E69QR18882; Wed, 13 Mar 2002 22:09:27 -0800 Date: Wed, 13 Mar 2002 22:09:26 -0800 (PST) From: X-X-Sender: To: Xiaoning He cc: Subject: Re: Kernel Memory Functions In-Reply-To: <000601c1caee$805277c0$326015ac@DOCOMOHE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1247 Lines: 40 On Wed, 13 Mar 2002, Xiaoning He wrote: | I am trying to modify the kernel. I need some memory operations | including memset, memcpy, malloc etc. | | I was told that these functions are not available in the kernel | namespace, and I have to use some different functions like kmalloc() | etc. However, I can not find the information about how to use these | functions. What kernel version and what CPU type? These can affect the answer. For 2.4.x (looking at 2.4.17): kmalloc() and kfree() function prototypes are in linux/include/linux/slab.h . Depending on cpu_type, memset() and memcpy() might or might not be inline functions. Their function prototypes and/or inlines are in linux/include/asm-/string.h . | Could you please let me know where I can find the information about how | to use these functions? If you have the necessary DocBook tools (or are willing to install them), you can do make psdocs pdfdocs htmldocs # any or all of these to create kernel doc. files in linux/Documentation/DocBook/*, then look at kernel-api.* for kernel API information. Or you could get Linux Device Drivers (second edition) in paper form or find it on the web (free :) at http://www.xml.com/ldd/chapter/book/index.html -- ~Randy From owner-netdev@oss.sgi.com Thu Mar 14 08:19:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EGJqF09573 for netdev-outgoing; Thu, 14 Mar 2002 08:19:52 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EGJh909569 for ; Thu, 14 Mar 2002 08:19:43 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA14926; Thu, 14 Mar 2002 11:17:47 -0500 Received: from d03nm035.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2EGKwm120884; Thu, 14 Mar 2002 09:20:58 -0700 From: "Nivedita Singhvi" Importance: Normal Sensitivity: Subject: Re: Deadlock problem with TCP v6? To: Pekka Savola Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Thu, 14 Mar 2002 08:20:57 -0800 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.9a |January 7, 2002) at 03/14/2002 09:20:57 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2544 Lines: 82 Pekka, You dont say where you were running the trace. > - Linux 2.4.9 (at least) works (the same system) > > - Linux 2.4.9, 2.4.12, 2.4.18 and other versions > do work from some other topological locations: it > seems that this happens only if the latency between > the boxes is very low. > > Perhaps some TCP specilist can shed some light on this? There is nothing inherently wrong in the flow of events, although there is a loss of a packet. > 17:12:51.254612 2001:708:10:10:250:4ff:fe6a:db55.1046 > > 2001:708:10:f::c1a6:45.http: S [tcp sum ok] > 3514706145:3514706145(0) win 5760 timestamp 100174 0,nop,wscale 0> (len 40, hlim 64) > 17:12:51.259395 2001:708:10:f::c1a6:45.http > > 2001:708:10:10:250:4ff:fe6a:db55.1046: S [tcp sum ok] > 2663223199:2663223199(0) ack 3514706146 win 65535 > 100174> (len 40, hlim 61) > 17:12:51.259457 2001:708:10:10:250:4ff:fe6a:db55.1046 > > 2001:708:10:f::c1a6:45.http: . [tcp sum ok] 1:1(0) > ack 1 win 5760 > (len 32, hlim 64) Normal 3 way handshake > 17:12:51.260802 2001:708:10:10:250:4ff:fe6a:db55.1046 > > 2001:708:10:f::c1a6:45.http: P 1:537(536) ack 1 > win 5760 > (len 568, hlim 64) Linux client sends the get request, bytes 1:536 > 17:12:51.468662 2001:708:10:10:250:4ff:fe6a:db55.1046 > > 2001:708:10:f::c1a6:45.http: P 1:537(536) ack 1 > win 5760 > (len 568, hlim 64) ~200ms seconds later, the retransmission timer goes off at the Linux client, not having received an ack in reply so far. It resends the data (1:536 bytes). > 17:12:51.474158 2001:708:10:f::c1a6:45.http > > 2001:708:10:10:250:4ff:fe6a:db55.1046: . [tcp sum ok] > 2857:2857(0) ack 537 win 32844 218472670 100196> [flowlabel 0x60695] (len 32, hlim 61) Freebsd almost immediately sends an ack back for the 536 bytes, which means it got the retransmitted data packet. I'm not sure why you see nothing more in the trace here - you should see the http send from the freebsd box. Any thoughts? Does this appear to be a FreeBSD or Linux problem? (I'd be tempted to say Linux, because it works in some versions but not others.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Fri Mar 15 02:49:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FAnSt23367 for netdev-outgoing; Fri, 15 Mar 2002 02:49:28 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FAmc923355 for ; Fri, 15 Mar 2002 02:48:38 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2FAnvl00624; Fri, 15 Mar 2002 12:49:57 +0200 Date: Fri, 15 Mar 2002 12:49:57 +0200 (EET) From: Pekka Savola To: Nivedita Singhvi cc: netdev@oss.sgi.com Subject: Re: Deadlock problem with TCP v6? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1818960107-1016189397=:600" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 26168 Lines: 451 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1589707168-1818960107-1016189397=:600 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Mar 2002, Nivedita Singhvi wrote: > You dont say where you were running the trace. Sorry, forgot. One can see from the direction of tcpdumps that it was run on the Linux client though. > Freebsd almost immediately sends an ack back > for the 536 bytes, which means it got the > retransmitted data packet. > > I'm not sure why you see nothing more in the > trace here - you should see the http send from > the freebsd box. Ok.. when trying to figure this out, I just installed a regular webserver on the FreeBSD TCP relay's port 8000, with really unexpected results: 1) linux-testbox$ lynx www.ipv6.csc.fi [goes through the relay] [no luck, ^C] 2) linux-testbox$ lynx http://[2001:708:0:1::624]:8000 [on the relay] [works without problems] 3) linux-testbox$ lynx www.ipv6.csc.fi [now this works too!!!!!] Tcpdump of linux (pstest.log) and relay (sixpack.log) are attached. This seem to be a few fragments flying around, so I wonder if that has anything to do with this. Any thoughts? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords --1589707168-1818960107-1016189397=:600 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="pstest.log" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="pstest.log" MTE6MzE6MDMuMDk3ODU4IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpk YjU1LjEwMzUgPiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1Lmh0dHA6IFMgW3Rj cCBzdW0gb2tdIDIxNDEzMDA5MzQ6MjE0MTMwMDkzNCgwKSB3aW4gNTc2MCA8 bXNzIDE0NDAsc2Fja09LLHRpbWVzdGFtcCAxMzg0NjEgMCxub3Asd3NjYWxl IDA+IChsZW4gNDAsIGhsaW0gNjQpDQoxMTozMTowMy4xMDMyMDQgMjAwMTo3 MDg6MTA6Zjo6YzFhNjo0NS5odHRwID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRm ZjpmZTZhOmRiNTUuMTAzNTogUyBbdGNwIHN1bSBva10gMTU0NDIyMjE2OjE1 NDQyMjIxNigwKSBhY2sgMjE0MTMwMDkzNSB3aW4gNjU1MzUgPG1zcyAxNDQw LG5vcCx3c2NhbGUgMSxub3Asbm9wLHRpbWVzdGFtcCA1MTY0NiAxMzg0NjE+ IChsZW4gNDAsIGhsaW0gNjEpDQoxMTozMTowMy4xMDMyNjIgMjAwMTo3MDg6 MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAzNSA+IDIwMDE6NzA4OjEwOmY6 OmMxYTY6NDUuaHR0cDogLiBbdGNwIHN1bSBva10gMToxKDApIGFjayAxIHdp biA1NzYwIDxub3Asbm9wLHRpbWVzdGFtcCAxMzg0NjEgNTE2NDY+IChsZW4g MzIsIGhsaW0gNjQpDQoxMTozMTowMy4xMDQ2ODEgMjAwMTo3MDg6MTA6MTA6 MjUwOjRmZjpmZTZhOmRiNTUuMTAzNSA+IDIwMDE6NzA4OjEwOmY6OmMxYTY6 NDUuaHR0cDogUCBbdGNwIHN1bSBva10gMTo1MzcoNTM2KSBhY2sgMSB3aW4g NTc2MCA8bm9wLG5vcCx0aW1lc3RhbXAgMTM4NDYxIDUxNjQ2PiAobGVuIDU2 OCwgaGxpbSA2NCkNCjExOjMxOjAzLjMwNDcyOSAyMDAxOjcwODoxMDoxMDoy NTA6NGZmOmZlNmE6ZGI1NS4xMDM1ID4gMjAwMTo3MDg6MTA6Zjo6YzFhNjo0 NS5odHRwOiBQIFt0Y3Agc3VtIG9rXSAxOjUzNyg1MzYpIGFjayAxIHdpbiA1 NzYwIDxub3Asbm9wLHRpbWVzdGFtcCAxMzg0ODIgNTE2NDY+IChsZW4gNTY4 LCBobGltIDY0KQ0KMTE6MzE6MDMuMzEwMjc2IDIwMDE6NzA4OjEwOmY6OmMx YTY6NDUuaHR0cCA+IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1 LjEwMzU6IC4gW3RjcCBzdW0gb2tdIDI4NTc6Mjg1NygwKSBhY2sgNTM3IHdp biAzMjg0NCA8bm9wLG5vcCx0aW1lc3RhbXAgNTE2NjcgMTM4NDgyPiBbZmxv d2xhYmVsIDB4NTk4NDVdIChsZW4gMzIsIGhsaW0gNjEpDQoxMTozMTowOC41 OTAxNTIgMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAzNSA+ IDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUuaHR0cDogRiBbdGNwIHN1bSBva10g NTM3OjUzNygwKSBhY2sgMSB3aW4gNTc2MCA8bm9wLG5vcCx0aW1lc3RhbXAg MTM5MDEwIDUxNjQ2PiAobGVuIDMyLCBobGltIDY0KQ0KMTE6MzE6MDguNTk0 NTMzIDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUuaHR0cCA+IDIwMDE6NzA4OjEw OjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEwMzU6IC4gW3RjcCBzdW0gb2tdIDI4 NTc6Mjg1NygwKSBhY2sgNTM4IHdpbiAzMjg0MyA8bm9wLG5vcCx0aW1lc3Rh bXAgNTIxOTUgMTM5MDEwPiBbZmxvd2xhYmVsIDB4NTk4NDVdIChsZW4gMzIs IGhsaW0gNjEpDQoxMTozMToxNi42MDcxODEgMjAwMTo3MDg6MTA6MTA6MjUw OjRmZjpmZTZhOmRiNTUuMTAzNiA+IDIwMDE6NzA4OjA6MTo6NjI0LjgwMDA6 IFMgW3RjcCBzdW0gb2tdIDIxNTQ2NjA3NzU6MjE1NDY2MDc3NSgwKSB3aW4g NTc2MCA8bXNzIDE0NDAsc2Fja09LLHRpbWVzdGFtcCAxMzk4MTIgMCxub3As d3NjYWxlIDA+IChsZW4gNDAsIGhsaW0gNjQpDQoxMTozMToxNi42MTE5NDUg MjAwMTo3MDg6MDoxOjo2MjQuODAwMCA+IDIwMDE6NzA4OjEwOjEwOjI1MDo0 ZmY6ZmU2YTpkYjU1LjEwMzY6IFMgW3RjcCBzdW0gb2tdIDM1ODQ0MTI0MDoz NTg0NDEyNDAoMCkgYWNrIDIxNTQ2NjA3NzYgd2luIDY1NTM1IDxtc3MgMTQ0 MCxub3Asd3NjYWxlIDEsbm9wLG5vcCx0aW1lc3RhbXAgNTI5OTcgMTM5ODEy PiBbY2xhc3MgMHgxXSBbZmxvd2xhYmVsIDB4NWNdIChsZW4gNDAsIGhsaW0g NjEpDQoxMTozMToxNi42MTIwMTAgMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpm ZTZhOmRiNTUuMTAzNiA+IDIwMDE6NzA4OjA6MTo6NjI0LjgwMDA6IC4gW3Rj cCBzdW0gb2tdIDE6MSgwKSBhY2sgMSB3aW4gNTc2MCA8bm9wLG5vcCx0aW1l c3RhbXAgMTM5ODEyIDUyOTk3PiAobGVuIDMyLCBobGltIDY0KQ0KMTE6MzE6 MTYuNjEzMTkxIDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEw MzYgPiAyMDAxOjcwODowOjE6OjYyNC44MDAwOiBQIFt0Y3Agc3VtIG9rXSAx OjU0Nig1NDUpIGFjayAxIHdpbiA1NzYwIDxub3Asbm9wLHRpbWVzdGFtcCAx Mzk4MTIgNTI5OTc+IChsZW4gNTc3LCBobGltIDY0KQ0KMTE6MzE6MTYuNjUz NTEyIDIwMDE6NzA4OjA6MTo6NjI0LjgwMDAgPiAyMDAxOjcwODoxMDoxMDoy NTA6NGZmOmZlNmE6ZGI1NS4xMDM2OiBQIFt0Y3Agc3VtIG9rXSAxOjQ4Nig0 ODUpIGFjayA1NDYgd2luIDMyODQ0IDxub3Asbm9wLHRpbWVzdGFtcCA1MzAw MSAxMzk4MTI+IFtmbG93bGFiZWwgMHg1OTg0Nl0gKGxlbiA1MTcsIGhsaW0g NjEpDQoxMTozMToxNi42NTM2MDQgMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpm ZTZhOmRiNTUuMTAzNiA+IDIwMDE6NzA4OjA6MTo6NjI0LjgwMDA6IC4gW3Rj cCBzdW0gb2tdIDU0Njo1NDYoMCkgYWNrIDQ4NiB3aW4gNjQzMiA8bm9wLG5v cCx0aW1lc3RhbXAgMTM5ODE2IDUzMDAxPiAobGVuIDMyLCBobGltIDY0KQ0K MTE6MzE6MTYuNjU0MjEzIDIwMDE6NzA4OjA6MTo6NjI0LjgwMDAgPiAyMDAx OjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM2OiBQIFt0Y3Agc3Vt IG9rXSAxOTE0OjE5NDIoMjgpIGFjayA1NDYgd2luIDMyODQ0IDxub3Asbm9w LHRpbWVzdGFtcCA1MzAwMSAxMzk4MTI+IFtmbG93bGFiZWwgMHg1OTg0Nl0g KGxlbiA2MCwgaGxpbSA2MSkNCjExOjMxOjE2LjY1NDI2MiAyMDAxOjcwODox MDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM2ID4gMjAwMTo3MDg6MDoxOjo2 MjQuODAwMDogLiBbdGNwIHN1bSBva10gNTQ2OjU0NigwKSBhY2sgNDg2IHdp biA2NDMyIDxub3Asbm9wLHRpbWVzdGFtcCAxMzk4MTcgNTMwMDE+IChsZW4g MzIsIGhsaW0gNjQpDQoxMTozMToxNi42NTk4MTEgMjAwMTo3MDg6MDoxOjo2 MjQuODAwMCA+IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEw MzY6IC4gW3RjcCBzdW0gb2tdIDE6MTQwOSgxNDA4KSBhY2sgNTQ2IHdpbiAz Mjg0NCA8bm9wLG5vcCx0aW1lc3RhbXAgNTMwMDEgMTM5ODEyPiBbZmxvd2xh YmVsIDB4NTk4NDZdIChsZW4gMTQ0MCwgaGxpbSA2MSkNCjExOjMxOjE2LjY1 OTg4OSAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM2ID4g MjAwMTo3MDg6MDoxOjo2MjQuODAwMDogLiBbdGNwIHN1bSBva10gNTQ2OjU0 NigwKSBhY2sgMTQwOSB3aW4gODQ0OCA8bm9wLG5vcCx0aW1lc3RhbXAgMTM5 ODE3IDUzMDAxPiAobGVuIDMyLCBobGltIDY0KQ0KMTE6MzE6MTYuNjYwMzE5 IDIwMDE6NzA4OjA6MTo6NjI0LjgwMDAgPiAyMDAxOjcwODoxMDoxMDoyNTA6 NGZmOmZlNmE6ZGI1NS4xMDM2OiBQIFt0Y3Agc3VtIG9rXSAxNDA5OjE5NDIo NTMzKSBhY2sgNTQ2IHdpbiAzMjg0NCA8bm9wLG5vcCx0aW1lc3RhbXAgNTMw MDEgMTM5ODEyPiBbZmxvd2xhYmVsIDB4NTk4NDZdIChsZW4gNTY1LCBobGlt IDYxKQ0KMTE6MzE6MTYuNjYwMzk2IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6 ZmU2YTpkYjU1LjEwMzYgPiAyMDAxOjcwODowOjE6OjYyNC44MDAwOiAuIFt0 Y3Agc3VtIG9rXSA1NDY6NTQ2KDApIGFjayAxOTQyIHdpbiAxMTI2NCA8bm9w LG5vcCx0aW1lc3RhbXAgMTM5ODE3IDUzMDAxPiAobGVuIDMyLCBobGltIDY0 KQ0KMTE6MzE6MTYuNjczMDIwIDIwMDE6NzA4OjA6MTo6NjI0LjgwMDAgPiAy MDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM2OiBGIFt0Y3Ag c3VtIG9rXSAxOTQyOjE5NDIoMCkgYWNrIDU0NiB3aW4gMzI4NDQgPG5vcCxu b3AsdGltZXN0YW1wIDUzMDAzIDEzOTgxNz4gW2Zsb3dsYWJlbCAweDU5ODQ2 XSAobGVuIDMyLCBobGltIDYxKQ0KMTE6MzE6MTYuNjczNjkyIDIwMDE6NzA4 OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEwMzYgPiAyMDAxOjcwODowOjE6 OjYyNC44MDAwOiBGIFt0Y3Agc3VtIG9rXSA1NDY6NTQ2KDApIGFjayAxOTQz IHdpbiAxMTI2NCA8bm9wLG5vcCx0aW1lc3RhbXAgMTM5ODE4IDUzMDAzPiAo bGVuIDMyLCBobGltIDY0KQ0KMTE6MzE6MTYuNjc3ODE0IDIwMDE6NzA4OjA6 MTo6NjI0LjgwMDAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1 NS4xMDM2OiAuIFt0Y3Agc3VtIG9rXSAxOTQzOjE5NDMoMCkgYWNrIDU0NyB3 aW4gMzI4NDQgPG5vcCxub3AsdGltZXN0YW1wIDUzMDA0IDEzOTgxOD4gW2Zs b3dsYWJlbCAweDU5ODQ2XSAobGVuIDMyLCBobGltIDYxKQ0KMTE6MzE6MTgu MTYwNzg4IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEwMzUg PiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1Lmh0dHA6IFIgW3RjcCBzdW0gb2td IDIxNDEzMDE0NzI6MjE0MTMwMTQ3MigwKSB3aW4gMCAobGVuIDIwLCBobGlt IDY0KQ0KMTE6MzE6MjIuMzgyMzkwIDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6 ZmU2YTpkYjU1LjEwMzcgPiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1Lmh0dHA6 IFMgW3RjcCBzdW0gb2tdIDIxNjE4ODY5NDM6MjE2MTg4Njk0MygwKSB3aW4g NTc2MCA8bXNzIDE0NDAsc2Fja09LLHRpbWVzdGFtcCAxNDAzODkgMCxub3As d3NjYWxlIDA+IChsZW4gNDAsIGhsaW0gNjQpDQoxMTozMToyMi4zODY4Mzgg MjAwMTo3MDg6MTA6Zjo6YzFhNjo0NS5odHRwID4gMjAwMTo3MDg6MTA6MTA6 MjUwOjRmZjpmZTZhOmRiNTUuMTAzNzogUyBbdGNwIHN1bSBva10gMzM0ODMx MDE2OjMzNDgzMTAxNigwKSBhY2sgMjE2MTg4Njk0NCB3aW4gNjU1MzUgPG1z cyAxNDQwLG5vcCx3c2NhbGUgMSxub3Asbm9wLHRpbWVzdGFtcCA1MzU3NCAx NDAzODk+IFtjbGFzcyAweDFdIFtmbG93bGFiZWwgMHg1Y10gKGxlbiA0MCwg aGxpbSA2MSkNCjExOjMxOjIyLjM4Njg5OSAyMDAxOjcwODoxMDoxMDoyNTA6 NGZmOmZlNmE6ZGI1NS4xMDM3ID4gMjAwMTo3MDg6MTA6Zjo6YzFhNjo0NS5o dHRwOiAuIFt0Y3Agc3VtIG9rXSAxOjEoMCkgYWNrIDEgd2luIDU3NjAgPG5v cCxub3AsdGltZXN0YW1wIDE0MDM5MCA1MzU3ND4gKGxlbiAzMiwgaGxpbSA2 NCkNCjExOjMxOjIyLjM4ODMxMiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZl NmE6ZGI1NS4xMDM3ID4gMjAwMTo3MDg6MTA6Zjo6YzFhNjo0NS5odHRwOiBQ IFt0Y3Agc3VtIG9rXSAxOjUzNyg1MzYpIGFjayAxIHdpbiA1NzYwIDxub3As bm9wLHRpbWVzdGFtcCAxNDAzOTAgNTM1NzQ+IChsZW4gNTY4LCBobGltIDY0 KQ0KMTE6MzE6MjIuNDQ4MzY3IDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUuaHR0 cCA+IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEwMzc6IC4g W3RjcCBzdW0gb2tdIDE6MTQwOSgxNDA4KSBhY2sgNTM3IHdpbiAzMzA4OCA8 bm9wLG5vcCx0aW1lc3RhbXAgNTM1ODAgMTQwMzkwPiBbZmxvd2xhYmVsIDB4 NTk4NDddIChsZW4gMTQ0MCwgaGxpbSA2MSkNCjExOjMxOjIyLjQ0ODQ2MSAy MDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM3ID4gMjAwMTo3 MDg6MTA6Zjo6YzFhNjo0NS5odHRwOiAuIFt0Y3Agc3VtIG9rXSA1Mzc6NTM3 KDApIGFjayAxNDA5IHdpbiA4NDQ4IDxub3Asbm9wLHRpbWVzdGFtcCAxNDAz OTYgNTM1ODA+IChsZW4gMzIsIGhsaW0gNjQpDQoxMTozMToyMi40NDk2MDMg MjAwMTo3MDg6MTA6Zjo6YzFhNjo0NS5odHRwID4gMjAwMTo3MDg6MTA6MTA6 MjUwOjRmZjpmZTZhOmRiNTUuMTAzNzogLiBbdGNwIHN1bSBva10gMTQwOToy ODE3KDE0MDgpIGFjayA1Mzcgd2luIDMzMDg4IDxub3Asbm9wLHRpbWVzdGFt cCA1MzU4MCAxNDAzOTA+IFtmbG93bGFiZWwgMHg1OTg0N10gKGxlbiAxNDQw LCBobGltIDYxKQ0KMTE6MzE6MjIuNDQ5NjgyIDIwMDE6NzA4OjEwOjEwOjI1 MDo0ZmY6ZmU2YTpkYjU1LjEwMzcgPiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1 Lmh0dHA6IC4gW3RjcCBzdW0gb2tdIDUzNzo1MzcoMCkgYWNrIDI4MTcgd2lu IDExMjY0IDxub3Asbm9wLHRpbWVzdGFtcCAxNDAzOTYgNTM1ODA+IChsZW4g MzIsIGhsaW0gNjQpDQoxMTozMToyMi40NTc2NjIgMjAwMTo3MDg6MTA6Zjo6 YzFhNjo0NS5odHRwID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRi NTUuMTAzNzogLiBbdGNwIHN1bSBva10gMjgxNzo0MjI1KDE0MDgpIGFjayA1 Mzcgd2luIDMzMDg4IDxub3Asbm9wLHRpbWVzdGFtcCA1MzU4MSAxNDAzOTY+ IFtmbG93bGFiZWwgMHg1OTg0N10gKGxlbiAxNDQwLCBobGltIDYxKQ0KMTE6 MzE6MjIuNDU3NzQzIDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1 LjEwMzcgPiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1Lmh0dHA6IC4gW3RjcCBz dW0gb2tdIDUzNzo1MzcoMCkgYWNrIDQyMjUgd2luIDE0MDgwIDxub3Asbm9w LHRpbWVzdGFtcCAxNDAzOTcgNTM1ODE+IChsZW4gMzIsIGhsaW0gNjQpDQox MTozMToyMi40NTg4NzUgMjAwMTo3MDg6MTA6Zjo6YzFhNjo0NS5odHRwID4g MjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAzNzogLiBbdGNw IHN1bSBva10gNDIyNTo1NjMzKDE0MDgpIGFjayA1Mzcgd2luIDMzMDg4IDxu b3Asbm9wLHRpbWVzdGFtcCA1MzU4MSAxNDAzOTY+IFtmbG93bGFiZWwgMHg1 OTg0N10gKGxlbiAxNDQwLCBobGltIDYxKQ0KMTE6MzE6MjIuNDU4OTQ1IDIw MDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEwMzcgPiAyMDAxOjcw ODoxMDpmOjpjMWE2OjQ1Lmh0dHA6IC4gW3RjcCBzdW0gb2tdIDUzNzo1Mzco MCkgYWNrIDU2MzMgd2luIDE2ODk2IDxub3Asbm9wLHRpbWVzdGFtcCAxNDAz OTcgNTM1ODE+IChsZW4gMzIsIGhsaW0gNjQpDQoxMTozMToyMi40NTkyODYg MjAwMTo3MDg6MTA6Zjo6YzFhNjo0NS5odHRwID4gMjAwMTo3MDg6MTA6MTA6 MjUwOjRmZjpmZTZhOmRiNTUuMTAzNzogRlAgW3RjcCBzdW0gb2tdIDU2MzM6 NjAxMygzODApIGFjayA1Mzcgd2luIDMzMDg4IDxub3Asbm9wLHRpbWVzdGFt cCA1MzU4MSAxNDAzOTY+IFtmbG93bGFiZWwgMHg1OTg0N10gKGxlbiA0MTIs IGhsaW0gNjEpDQoxMTozMToyMi40NzU0NDUgMjAwMTo3MDg6MTA6MTA6MjUw OjRmZjpmZTZhOmRiNTUuMTAzNyA+IDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUu aHR0cDogRiBbdGNwIHN1bSBva10gNTM3OjUzNygwKSBhY2sgNjAxNCB3aW4g MTY4OTYgPG5vcCxub3AsdGltZXN0YW1wIDE0MDM5OSA1MzU4MT4gKGxlbiAz MiwgaGxpbSA2NCkNCjExOjMxOjIyLjQ4MDcwNSAyMDAxOjcwODoxMDpmOjpj MWE2OjQ1Lmh0dHAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1 NS4xMDM3OiAuIFt0Y3Agc3VtIG9rXSA2MDE0OjYwMTQoMCkgYWNrIDUzOCB3 aW4gMzMwODcgPG5vcCxub3AsdGltZXN0YW1wIDUzNTg0IDE0MDM5OT4gW2Zs b3dsYWJlbCAweDU5ODQ3XSAobGVuIDMyLCBobGltIDYxKQ0K --1589707168-1818960107-1016189397=:600 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sixpack.log" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="sixpack.log" c2l4cGFjayMgdGNwZHVtcCAtciBsb2cgLW4gLXMgMTUwMCAtdiAtdiAtdg0K MTE6MzE6MDMuMTM4NDUzIDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpk YjU1LjEwMzUgPiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1LjgwOiBTIFt0Y3Ag c3VtIG9rXSAyMTQxMzAwOTM0OjIxNDEzMDA5MzQoMCkgd2luIDU3NjAgPG1z cyAxNDQwLHNhY2tPSyx0aW1lc3RhbXAgMTM4NDYxIDAsbm9wLHdzY2FsZSAw PiAobGVuIDQwLCBobGltIDYxKQ0KMTE6MzE6MDMuMTM4OTM0IDIwMDE6NzA4 OjEwOmY6OmMxYTY6NDUuODAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZl NmE6ZGI1NS4xMDM1OiBTIFt0Y3Agc3VtIG9rXSAxNTQ0MjIyMTY6MTU0NDIy MjE2KDApIGFjayAyMTQxMzAwOTM1IHdpbiA2NTUzNSA8bXNzIDE0NDAsbm9w LHdzY2FsZSAxLG5vcCxub3AsdGltZXN0YW1wIDUxNjQ2IDEzODQ2MT4gKGxl biA0MCwgaGxpbSA2NCkNCjExOjMxOjAzLjE0MzM0MSAyMDAxOjcwODoxMDox MDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM1ID4gMjAwMTo3MDg6MTA6Zjo6YzFh Njo0NS44MDogLiBbdGNwIHN1bSBva10gMToxKDApIGFjayAxIHdpbiA1NzYw IDxub3Asbm9wLHRpbWVzdGFtcCAxMzg0NjEgNTE2NDY+IChsZW4gMzIsIGhs aW0gNjEpDQoxMTozMTowMy4xNDU4MzEgMjAwMTo3MDg6MTA6MTA6MjUwOjRm ZjpmZTZhOmRiNTUuMTAzNSA+IDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUuODA6 IFAgW3RjcCBzdW0gb2tdIDE6NTM3KDUzNikgYWNrIDEgd2luIDU3NjAgPG5v cCxub3AsdGltZXN0YW1wIDEzODQ2MSA1MTY0Nj4gKGxlbiA1NjgsIGhsaW0g NjEpDQoxMTozMTowMy4xOTcyMjggMjAwMTo3MDg6MTA6Zjo6YzFhNjo0NS44 MCA+IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEwMzU6IC4g MToxNDI5KDE0MjgpIGFjayA1Mzcgd2luIDMyODQ0IDxub3Asbm9wLHRpbWVz dGFtcCA1MTY1MiAxMzg0NjE+IFtmbG93bGFiZWwgMHg1OTg0NV0gKGxlbiAx NDYwLCBobGltIDY0KQ0KMTE6MzE6MDMuMTk3NTI4IDIwMDE6NzA4OjEwOmY6 OmMxYTY6NDUuODAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1 NS4xMDM1OiAuIDE0Mjk6Mjg1NygxNDI4KSBhY2sgNTM3IHdpbiAzMjg0NCA8 bm9wLG5vcCx0aW1lc3RhbXAgNTE2NTIgMTM4NDYxPiBbZmxvd2xhYmVsIDB4 NTk4NDVdIChsZW4gMTQ2MCwgaGxpbSA2NCkNCjExOjMxOjAzLjM0NjE1MiAy MDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM1ID4gMjAwMTo3 MDg6MTA6Zjo6YzFhNjo0NS44MDogUCBbdGNwIHN1bSBva10gMTo1MzcoNTM2 KSBhY2sgMSB3aW4gNTc2MCA8bm9wLG5vcCx0aW1lc3RhbXAgMTM4NDgyIDUx NjQ2PiAobGVuIDU2OCwgaGxpbSA2MSkNCjExOjMxOjAzLjM0NjY0OCAyMDAx OjcwODoxMDpmOjpjMWE2OjQ1LjgwID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRm ZjpmZTZhOmRiNTUuMTAzNTogLiBbdGNwIHN1bSBva10gMjg1NzoyODU3KDAp IGFjayA1Mzcgd2luIDMyODQ0IDxub3Asbm9wLHRpbWVzdGFtcCA1MTY2NyAx Mzg0ODI+IFtmbG93bGFiZWwgMHg1OTg0NV0gKGxlbiAzMiwgaGxpbSA2NCkN CjExOjMxOjA0LjE5MzY4MiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1LjgwID4g MjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAzNTogLiAxOjE0 MjkoMTQyOCkgYWNrIDUzNyB3aW4gMzI4NDQgPG5vcCxub3AsdGltZXN0YW1w IDUxNzUyIDEzODQ4Mj4gW2Zsb3dsYWJlbCAweDU5ODQ1XSAobGVuIDE0NjAs IGhsaW0gNjQpDQoxMTozMTowNi4xOTQ3MzMgMjAwMTo3MDg6MTA6Zjo6YzFh Njo0NS44MCA+IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEw MzU6IC4gMToxNDI5KDE0MjgpIGFjayA1Mzcgd2luIDMyODQ0IDxub3Asbm9w LHRpbWVzdGFtcCA1MTk1MiAxMzg0ODI+IFtmbG93bGFiZWwgMHg1OTg0NV0g KGxlbiAxNDYwLCBobGltIDY0KQ0KMTE6MzE6MDcuMDQ1MjQyIDIwMDE6NzA4 OjEwOmY6OmMxYTY6NDUuODAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZl NmE6ZGI1NS4xMDI4OiAuIDMzOTM3MzEyMTU6MzM5MzczMjY0MygxNDI4KSBh Y2sgMTc0MDk0MjA0NiB3aW4gMzI4NDMgPG5vcCxub3AsdGltZXN0YW1wIDUy MDM3IDEwMDY0MT4gW2Zsb3dsYWJlbCAweDU5ODNjXSAobGVuIDE0NjAsIGhs aW0gNjQpDQoxMTozMTowOC42MzMxNzUgMjAwMTo3MDg6MTA6MTA6MjUwOjRm ZjpmZTZhOmRiNTUuMTAzNSA+IDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUuODA6 IEYgW3RjcCBzdW0gb2tdIDUzNzo1MzcoMCkgYWNrIDEgd2luIDU3NjAgPG5v cCxub3AsdGltZXN0YW1wIDEzOTAxMCA1MTY0Nj4gKGxlbiAzMiwgaGxpbSA2 MSkNCjExOjMxOjA4LjYzMzU5OSAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1Ljgw ID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAzNTogLiBb dGNwIHN1bSBva10gMjg1NzoyODU3KDApIGFjayA1Mzggd2luIDMyODQzIDxu b3Asbm9wLHRpbWVzdGFtcCA1MjE5NSAxMzkwMTA+IFtmbG93bGFiZWwgMHg1 OTg0NV0gKGxlbiAzMiwgaGxpbSA2NCkNCjExOjMxOjA4LjcyNjAyMiAyMDAx OjcwODoxMDpmOjpjMWE2OjQ1LjgwID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRm ZjpmZTZhOmRiNTUuMTAyOTogLiAzNjk5MDU0NTYyOjM2OTkwNTU5OTAoMTQy OCkgYWNrIDE3NDYwMTQ5MzYgd2luIDMyODQzIDxub3Asbm9wLHRpbWVzdGFt cCA1MjIwNSAxMDA5NzM+IFtmbG93bGFiZWwgMHg1OTgzZF0gKGxlbiAxNDYw LCBobGltIDY0KQ0KMTE6MzE6MTAuMTk2Nzk1IDIwMDE6NzA4OjEwOmY6OmMx YTY6NDUuODAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4x MDM1OiAuIDE6MTQyOSgxNDI4KSBhY2sgNTM4IHdpbiAzMjg0MyA8bm9wLG5v cCx0aW1lc3RhbXAgNTIzNTIgMTM5MDEwPiBbZmxvd2xhYmVsIDB4NTk4NDVd IChsZW4gMTQ2MCwgaGxpbSA2NCkNCjExOjMxOjExLjg4NzcyNCAyMDAxOjcw ODoxMDpmOjpjMWE2OjQ1LjgwID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpm ZTZhOmRiNTUuMTAzMDogLiAxOTc5NDk2NzI4OjE5Nzk0OTgxNTYoMTQyOCkg YWNrIDE3NDkxOTc5MzIgd2luIDMyODQzIDxub3Asbm9wLHRpbWVzdGFtcCA1 MjUyMSAxMDExMzk+IFtmbG93bGFiZWwgMHg1OTgzZV0gKGxlbiAxNDYwLCBo bGltIDY0KQ0KMTE6MzE6MTYuNjU0Mzk3IDIwMDE6NzA4OjEwOjEwOjI1MDo0 ZmY6ZmU2YTpkYjU1LjEwMzYgPiAyMDAxOjcwODowOjE6OjYyNC44MDAwOiBT IFt0Y3Agc3VtIG9rXSAyMTU0NjYwNzc1OjIxNTQ2NjA3NzUoMCkgd2luIDU3 NjAgPG1zcyAxNDQwLHNhY2tPSyx0aW1lc3RhbXAgMTM5ODEyIDAsbm9wLHdz Y2FsZSAwPiAobGVuIDQwLCBobGltIDYxKQ0KMTE6MzE6MTYuNjU0ODMyIDIw MDE6NzA4OjA6MTo6NjI0LjgwMDAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZm OmZlNmE6ZGI1NS4xMDM2OiBTIFt0Y3Agc3VtIG9rXSAzNTg0NDEyNDA6MzU4 NDQxMjQwKDApIGFjayAyMTU0NjYwNzc2IHdpbiA2NTUzNSA8bXNzIDE0NDAs bm9wLHdzY2FsZSAxLG5vcCxub3AsdGltZXN0YW1wIDUyOTk3IDEzOTgxMj4g W2NsYXNzIDB4MV0gW2Zsb3dsYWJlbCAweDVjXSAobGVuIDQwLCBobGltIDY0 KQ0KMTE6MzE6MTYuNjU4OTEyIDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2 YTpkYjU1LjEwMzYgPiAyMDAxOjcwODowOjE6OjYyNC44MDAwOiAuIFt0Y3Ag c3VtIG9rXSAxOjEoMCkgYWNrIDEgd2luIDU3NjAgPG5vcCxub3AsdGltZXN0 YW1wIDEzOTgxMiA1Mjk5Nz4gKGxlbiAzMiwgaGxpbSA2MSkNCjExOjMxOjE2 LjY2MTEzMiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM2 ID4gMjAwMTo3MDg6MDoxOjo2MjQuODAwMDogUCBbdGNwIHN1bSBva10gMTo1 NDYoNTQ1KSBhY2sgMSB3aW4gNTc2MCA8bm9wLG5vcCx0aW1lc3RhbXAgMTM5 ODEyIDUyOTk3PiAobGVuIDU3NywgaGxpbSA2MSkNCjExOjMxOjE2LjY5NTQ4 MCAyMDAxOjcwODowOjE6OjYyNC44MDAwID4gMjAwMTo3MDg6MTA6MTA6MjUw OjRmZjpmZTZhOmRiNTUuMTAzNjogUCBbdGNwIHN1bSBva10gMTo0ODYoNDg1 KSBhY2sgNTQ2IHdpbiAzMjg0NCA8bm9wLG5vcCx0aW1lc3RhbXAgNTMwMDEg MTM5ODEyPiBbZmxvd2xhYmVsIDB4MTM5ODEyPiBbZmxvd2xhYmVsIDB4NTk4 NDZdIChsZW4gNTE3LCBobGltIDY0KQ0KMTE6MzE6MTYuNjk1NzU5IDIwMDE6 NzA4OjA6MTo6NjI0LjgwMDAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZl NmE6ZGI1NS4xMDM2OiAuIDQ4NjoxOTE0KDE0MjgpIGFjayA1NDYgd2luIDMy ODQ0IDxub3Asbm9wLHRpbWVzdGFtcCA1MzAwMSAxMzk4MTI+IFtmbG93bGFi ZWwgMHg1OTg0Nl0gKGxlbiAxNDYwLCBobGltIDY0KQ0KMTE6MzE6MTYuNjk1 OTUxIDIwMDE6NzA4OjA6MTo6NjI0LjgwMDAgPiAyMDAxOjcwODoxMDoxMDoy NTA6NGZmOmZlNmE6ZGI1NS4xMDM2OiBQIFt0Y3Agc3VtIG9rXSAxOTE0OjE5 NDIoMjgpIGFjayA1NDYgd2luIDMyODQ0IDxub3Asbm9wLHRpbWVzdGFtcCA1 MzAwMSAxMzk4MTI+IFtmbG93bGFiZWwgMHg1OTg0Nl0gKGxlbiA2MCwgaGxp bSA2NCkNCjExOjMxOjE2LjY5OTM2NSAyMDAxOjcwODowOjE6OjYyNC44MDAw ID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAzNjogLiBb dGNwIHN1bSBva10gMToxNDA5KDE0MDgpIGFjayA1NDYgd2luIDMyODQ0IDxu b3Asbm9wLHRpbWVzdGFtcCA1MzAwMSAxMzk4MTI+IFtmbG93bGFiZWwgMHg1 OTg0Nl0gKGxlbiAxNDQwLCBobGltIDY0KQ0KMTE6MzE6MTYuNjk5NTk1IDIw MDE6NzA4OjA6MTo6NjI0LjgwMDAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZm OmZlNmE6ZGI1NS4xMDM2OiBQIFt0Y3Agc3VtIG9rXSAxNDA5OjE5NDIoNTMz KSBhY2sgNTQ2IHdpbiAzMjg0NCA8bm9wLG5vcCx0aW1lc3RhbXAgNTMwMDEg MTM5ODEyPiBbZmxvd2xhYmVsIDB4NTk4NDZdIChsZW4gNTY1LCBobGltIDY0 KQ0KMTE6MzE6MTYuNzAxMzcyIDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2 YTpkYjU1LjEwMzYgPiAyMDAxOjcwODowOjE6OjYyNC44MDAwOiAuIFt0Y3Ag c3VtIG9rXSA1NDY6NTQ2KDApIGFjayA0ODYgd2luIDY0MzIgPG5vcCxub3As dGltZXN0YW1wIDEzOTgxNiA1MzAwMT4gKGxlbiAzMiwgaGxpbSA2MSkNCjEx OjMxOjE2LjcwMTYwMyAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1 NS4xMDM2ID4gMjAwMTo3MDg6MDoxOjo2MjQuODAwMDogLiBbdGNwIHN1bSBv a10gNTQ2OjU0NigwKSBhY2sgNDg2IHdpbiA2NDMyIDxub3Asbm9wLHRpbWVz dGFtcCAxMzk4MTcgNTMwMDE+IChsZW4gMzIsIGhsaW0gNjEpDQoxMTozMTox Ni43MDcyNzIgMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAz NiA+IDIwMDE6NzA4OjA6MTo6NjI0LjgwMDA6IC4gW3RjcCBzdW0gb2tdIDU0 Njo1NDYoMCkgYWNrIDE0MDkgd2luIDg0NDggPG5vcCxub3AsdGltZXN0YW1w IDEzOTgxNyA1MzAwMT4gKGxlbiAzMiwgaGxpbSA2MSkNCjExOjMxOjE2Ljcw NzQ3NiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM2ID4g MjAwMTo3MDg6MDoxOjo2MjQuODAwMDogLiBbdGNwIHN1bSBva10gNTQ2OjU0 NigwKSBhY2sgMTk0MiB3aW4gMTEyNjQgPG5vcCxub3AsdGltZXN0YW1wIDEz OTgxNyA1MzAwMT4gKGxlbiAzMiwgaGxpbSA2MSkNCjExOjMxOjE2LjcxNjI0 NyAyMDAxOjcwODowOjE6OjYyNC44MDAwID4gMjAwMTo3MDg6MTA6MTA6MjUw OjRmZjpmZTZhOmRiNTUuMTAzNjogRiBbdGNwIHN1bSBva10gMTk0MjoxOTQy KDApIGFjayA1NDYgd2luIDMyODQ0IDxub3Asbm9wLHRpbWVzdGFtcCA1MzAw MyAxMzk4MTc+IFtmbG93bGFiZWwgMHg1OTg0Nl0gKGxlbiAzMiwgaGxpbSA2 NCkNCjExOjMxOjE2LjcyMDU1NiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZl NmE6ZGI1NS4xMDM2ID4gMjAwMTo3MDg6MDoxOjo2MjQuODAwMDogRiBbdGNw IHN1bSBva10gNTQ2OjU0NigwKSBhY2sgMTk0MyB3aW4gMTEyNjQgPG5vcCxu b3AsdGltZXN0YW1wIDEzOTgxOCA1MzAwMz4gKGxlbiAzMiwgaGxpbSA2MSkN CjExOjMxOjE2LjcyMDkwMCAyMDAxOjcwODowOjE6OjYyNC44MDAwID4gMjAw MTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAzNjogLiBbdGNwIHN1 bSBva10gMTk0MzoxOTQzKDApIGFjayA1NDcgd2luIDMyODQ0IDxub3Asbm9w LHRpbWVzdGFtcCA1MzAwNCAxMzk4MTg+IFtmbG93bGFiZWwgMHg1OTg0Nl0g KGxlbiAzMiwgaGxpbSA2NCkNCjExOjMxOjE4LjIwMTA0MCAyMDAxOjcwODox MDpmOjpjMWE2OjQ1ID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRi NTU6IGZyYWcgKDB4MDAwM2UzNjQ6MHwxNDMyKSA4MCA+IDEwMzU6IC4gMTox NDAxKDE0MDApIGFjayA1Mzggd2luIDMyODQzIDxub3Asbm9wLHRpbWVzdGFt cCA1MzE1MiAxMzkwMTA+IFtmbG93bGFiZWwgMHg1OTg0NV0gKGxlbiAxNDQw LCBobGltIDY0KQ0KMTE6MzE6MTguMjAxMTMwIDIwMDE6NzA4OjEwOmY6OmMx YTY6NDUgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NTogZnJh ZyAoMHgwMDAzZTM2NDoxNDMyfDI4KSBbZmxvd2xhYmVsIDB4NTk4NDVdIChs ZW4gMzYsIGhsaW0gNjQpDQoxMTozMToxOC4yMDg0NTUgMjAwMTo3MDg6MTA6 MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAzNSA+IDIwMDE6NzA4OjEwOmY6OmMx YTY6NDUuODA6IFIgW3RjcCBzdW0gb2tdIDIxNDEzMDE0NzI6MjE0MTMwMTQ3 MigwKSB3aW4gMCAobGVuIDIwLCBobGltIDYxKQ0KMTE6MzE6MjIuNDMyMzI5 IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEwMzcgPiAyMDAx OjcwODoxMDpmOjpjMWE2OjQ1LjgwOiBTIFt0Y3Agc3VtIG9rXSAyMTYxODg2 OTQzOjIxNjE4ODY5NDMoMCkgd2luIDU3NjAgPG1zcyAxNDQwLHNhY2tPSyx0 aW1lc3RhbXAgMTQwMzg5IDAsbm9wLHdzY2FsZSAwPiAobGVuIDQwLCBobGlt IDYxKQ0KMTE6MzE6MjIuNDMyNzU4IDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUu ODAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM3OiBT IFt0Y3Agc3VtIG9rXSAzMzQ4MzEwMTY6MzM0ODMxMDE2KDApIGFjayAyMTYx ODg2OTQ0IHdpbiA2NTUzNSA8bXNzIDE0NDAsbm9wLHdzY2FsZSAxLG5vcCxu b3AsdGltZXN0YW1wIDUzNTc0IDE0MDM4OT4gW2NsYXNzIDB4MV0gW2Zsb3ds YWJlbCAweDVjXSAobGVuIDQwLCBobGltIDY0KQ0KMTE6MzE6MjIuNDM2NzM0 IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2YTpkYjU1LjEwMzcgPiAyMDAx OjcwODoxMDpmOjpjMWE2OjQ1LjgwOiAuIFt0Y3Agc3VtIG9rXSAxOjEoMCkg YWNrIDEgd2luIDU3NjAgPG5vcCxub3AsdGltZXN0YW1wIDE0MDM5MCA1MzU3 ND4gKGxlbiAzMiwgaGxpbSA2MSkNCjExOjMxOjIyLjQzOTExMyAyMDAxOjcw ODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM3ID4gMjAwMTo3MDg6MTA6 Zjo6YzFhNjo0NS44MDogUCBbdGNwIHN1bSBva10gMTo1MzcoNTM2KSBhY2sg MSB3aW4gNTc2MCA8bm9wLG5vcCx0aW1lc3RhbXAgMTQwMzkwIDUzNTc0PiAo bGVuIDU2OCwgaGxpbSA2MSkNCjExOjMxOjIyLjQ5MTAyMSAyMDAxOjcwODox MDpmOjpjMWE2OjQ1LjgwID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpmZTZh OmRiNTUuMTAzNzogLiBbdGNwIHN1bSBva10gMToxNDA5KDE0MDgpIGFjayA1 Mzcgd2luIDMzMDg4IDxub3Asbm9wLHRpbWVzdGFtcCA1MzU4MCAxNDAzOTA+ IFtmbG93bGFiZWwgMHg1OTg0N10gKGxlbiAxNDQwLCBobGltIDY0KQ0KMTE6 MzE6MjIuNDkxMzQ3IDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUuODAgPiAyMDAx OjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM3OiAuIFt0Y3Agc3Vt IG9rXSAxNDA5OjI4MTcoMTQwOCkgYWNrIDUzNyB3aW4gMzMwODggPG5vcCxu b3AsdGltZXN0YW1wIDUzNTgwIDE0MDM5MD4gW2Zsb3dsYWJlbCAweDU5ODQ3 XSAobGVuIDE0NDAsIGhsaW0gNjQpDQoxMTozMToyMi40OTk3MDUgMjAwMTo3 MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTUuMTAzNyA+IDIwMDE6NzA4OjEw OmY6OmMxYTY6NDUuODA6IC4gW3RjcCBzdW0gb2tdIDUzNzo1MzcoMCkgYWNr IDE0MDkgd2luIDg0NDggPG5vcCxub3AsdGltZXN0YW1wIDE0MDM5NiA1MzU4 MD4gKGxlbiAzMiwgaGxpbSA2MSkNCjExOjMxOjIyLjQ5OTg0OSAyMDAxOjcw ODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM3ID4gMjAwMTo3MDg6MTA6 Zjo6YzFhNjo0NS44MDogLiBbdGNwIHN1bSBva10gNTM3OjUzNygwKSBhY2sg MjgxNyB3aW4gMTEyNjQgPG5vcCxub3AsdGltZXN0YW1wIDE0MDM5NiA1MzU4 MD4gKGxlbiAzMiwgaGxpbSA2MSkNCjExOjMxOjIyLjUwMDI3MiAyMDAxOjcw ODoxMDpmOjpjMWE2OjQ1LjgwID4gMjAwMTo3MDg6MTA6MTA6MjUwOjRmZjpm ZTZhOmRiNTUuMTAzNzogLiBbdGNwIHN1bSBva10gMjgxNzo0MjI1KDE0MDgp IGFjayA1Mzcgd2luIDMzMDg4IDxub3Asbm9wLHRpbWVzdGFtcCA1MzU4MSAx NDAzOTY+IFtmbG93bGFiZWwgMHg1OTg0N10gKGxlbiAxNDQwLCBobGltIDY0 KQ0KMTE6MzE6MjIuNTAwNTI2IDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUuODAg PiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM3OiAuIFt0 Y3Agc3VtIG9rXSA0MjI1OjU2MzMoMTQwOCkgYWNrIDUzNyB3aW4gMzMwODgg PG5vcCxub3AsdGltZXN0YW1wIDUzNTgxIDE0MDM5Nj4gW2Zsb3dsYWJlbCAw eDU5ODQ3XSAobGVuIDE0NDAsIGhsaW0gNjQpDQoxMTozMToyMi41MDE3NjQg MjAwMTo3MDg6MTA6Zjo6YzFhNjo0NS44MCA+IDIwMDE6NzA4OjEwOjEwOjI1 MDo0ZmY6ZmU2YTpkYjU1LjEwMzc6IEZQIFt0Y3Agc3VtIG9rXSA1NjMzOjYw MTMoMzgwKSBhY2sgNTM3IHdpbiAzMzA4OCA8bm9wLG5vcCx0aW1lc3RhbXAg NTM1ODEgMTQwMzk2PiBbZmxvd2xhYmVsIDB4NTk4NDddIChsZW4gNDEyLCBo bGltIDY0KQ0KMTE6MzE6MjIuNTA5MzY5IDIwMDE6NzA4OjEwOjEwOjI1MDo0 ZmY6ZmU2YTpkYjU1LjEwMzcgPiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1Ljgw OiAuIFt0Y3Agc3VtIG9rXSA1Mzc6NTM3KDApIGFjayA0MjI1IHdpbiAxNDA4 MCA8bm9wLG5vcCx0aW1lc3RhbXAgMTQwMzk3IDUzNTgxPiAobGVuIDMyLCBo bGltIDYxKQ0KMTE6MzE6MjIuNTA5NTI1IDIwMDE6NzA4OjEwOjEwOjI1MDo0 ZmY6ZmU2YTpkYjU1LjEwMzcgPiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1Ljgw OiAuIFt0Y3Agc3VtIG9rXSA1Mzc6NTM3KDApIGFjayA1NjMzIHdpbiAxNjg5 NiA8bm9wLG5vcCx0aW1lc3RhbXAgMTQwMzk3IDUzNTgxPiAobGVuIDMyLCBo bGltIDYxKQ0KMTE6MzE6MjIuNTI2NDQxIDIwMDE6NzA4OjEwOjEwOjI1MDo0 ZmY6ZmU2YTpkYjU1LjEwMzcgPiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1Ljgw OiBGIFt0Y3Agc3VtIG9rXSA1Mzc6NTM3KDApIGFjayA2MDE0IHdpbiAxNjg5 NiA8bm9wLG5vcCx0aW1lc3RhbXAgMTQwMzk5IDUzNTgxPiAobGVuIDMyLCBo bGltIDYxKQ0KMTE6MzE6MjIuNTI2NzU0IDIwMDE6NzA4OjEwOmY6OmMxYTY6 NDUuODAgPiAyMDAxOjcwODoxMDoxMDoyNTA6NGZmOmZlNmE6ZGI1NS4xMDM3 OiAuIFt0Y3Agc3VtIG9rXSA2MDE0OjYwMTQoMCkgYWNrIDUzOCB3aW4gMzMw ODcgPG5vcCxub3AsdGltZXN0YW1wIDUzNTg0IDE0MDM5OT4gW2Zsb3dsYWJl bCAweDU5ODQ3XSAobGVuIDMyLCBobGltIDY0KQ0KMTE6MzE6MzMuNDc4ODUy IDIwMDE6NzA4OjEwOmY6OmMxYTY6NDUgPiAyMDAxOjcwODoxMDoxMDoyNTA6 NGZmOmZlNmE6ZGI1NTogZnJhZyAoMHgwMDAzZTM2NTowfDE0MzIpIDgwID4g MTAzMjogLiA5OTIxOTc1MjM6OTkyMTk4OTIzKDE0MDApIGFjayAyMDI5MjA2 OTExIHdpbiAzMjg0MyA8bm9wLG5vcCx0aW1lc3RhbXAgNTQ2NzkgMTI4ODgw PiBbZmxvd2xhYmVsIDB4NTk4NDJdIChsZW4gMTQ0MCwgaGxpbSA2NCkNCjEx OjMxOjMzLjQ3ODkzNCAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1ID4gMjAwMTo3 MDg6MTA6MTA6MjUwOjRmZjpmZTZhOmRiNTU6IGZyYWcgKDB4MDAwM2UzNjU6 MTQzMnwyOCkgW2Zsb3dsYWJlbCAweDU5ODQyXSAobGVuIDM2LCBobGltIDY0 KQ0KMTE6MzE6MzMuNDg2MTk4IDIwMDE6NzA4OjEwOjEwOjI1MDo0ZmY6ZmU2 YTpkYjU1LjEwMzIgPiAyMDAxOjcwODoxMDpmOjpjMWE2OjQ1LjgwOiBSIFt0 Y3Agc3VtIG9rXSAyMDI5MjA2OTExOjIwMjkyMDY5MTEoMCkgd2luIDAgKGxl biAyMCwgaGxpbSA2MSkNCg== --1589707168-1818960107-1016189397=:600-- From owner-netdev@oss.sgi.com Fri Mar 15 03:51:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FBpeK24777 for netdev-outgoing; Fri, 15 Mar 2002 03:51:40 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FBpO924773 for ; Fri, 15 Mar 2002 03:51:24 -0800 Received: from adsl-33-164-88.asm.bellsouth.net ([67.33.164.88] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16lqGS-00068U-00; Fri, 15 Mar 2002 11:52:52 +0000 Message-ID: <3C91E083.5070302@mandrakesoft.com> Date: Fri, 15 Mar 2002 06:52:35 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Patches sent to Linus Content-Type: multipart/mixed; boundary="------------080406040607000202030705" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4995 Lines: 138 This is a multi-part message in MIME format. --------------080406040607000202030705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------080406040607000202030705 Content-Type: text/plain; name="net-drivers-2.5.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="net-drivers-2.5.txt" Linus, please do a bk pull http://gkernel.bkbits.net/net-drivers-2.5 This will update the following files: drivers/net/acenic.c | 280 +++++++++++++++++++++++++++++-------- drivers/net/acenic.h | 41 ++++- drivers/net/at1700.c | 1 drivers/net/e100/e100.h | 41 ++--- drivers/net/e100/e100_config.c | 13 - drivers/net/e100/e100_config.h | 13 - drivers/net/e100/e100_eeprom.c | 38 ++--- drivers/net/e100/e100_main.c | 125 +++++++--------- drivers/net/e100/e100_phy.c | 56 +++---- drivers/net/e100/e100_phy.h | 13 - drivers/net/e100/e100_proc.c | 18 +- drivers/net/e100/e100_ucode.h | 13 - drivers/net/e100/e100_vendor.h | 13 - drivers/net/e1000/e1000_main.c | 2 drivers/net/eepro100.c | 1 drivers/net/hp100.c | 59 ++++++- drivers/net/lance.c | 2 drivers/net/ns83820.c | 303 ++++++++++++++++++++++++----------------- drivers/net/pcnet32.c | 24 ++- 19 files changed, 652 insertions(+), 404 deletions(-) through these ChangeSets: (02/03/15 1.487) Fix e1000 net driver build with newer binutils. (02/03/15 1.486) Don't include linux/delay.h twice in eepro100 net driver. Noticed by Alan Cox. (02/03/15 1.485) Convert hp100 net driver to PCI DMA mapping API. (fixes build) (02/03/15 1.484) lance net driver update: mark lance_probe as __init (02/03/15 1.483) acenic gige net driver update: merge VLAN support from 2.4.x kernel (02/03/15 1.482) acenic gige net driver fixes: * fix Tigon I support * fix memory leak (02/03/15 1.481) acenic gige net driver updates: * various small cleanups * ETHTOOL_GDRVINFO support (02/03/15 1.479) e100 net driver update 4/4: - switch to yield function as suggested by you, Arjan and Andrew. - fixed broken logic in the use of time_before/time_after - possible bug cause in previous design - in most of the places we were going to sleep and than check if time expires before checking if condition is satisfied. If, for example, we needed to wait up to 3 jiffies we could do schedule_timeout(1) and get up after 4 ticks check that time expired and go away crying about failure without checking that condition is OK.(in fact I saw it happen on one SMP platform here). (02/03/15 1.478) e100 net driver update 3/4: - added pci flushing in the e100_set_intr_mask function (pci posting bug) - better logic in the prepare_xmit_buff function moving some tx buffer initialization code to the start of the function. (02/03/15 1.477) e100 net driver update 2/4: - remove dummy defines and also ia64 specific [Arjan's notes [:-)] ] - fixed problem in e100_check_options function reported by our Q/A (02/03/15 1.476) e100 net driver update 1/4: - minor changes to the license from our technical writer [still GPL ;-)] (02/03/15 1.475) Updates to ns83820 gige net driver: * Use likely() and unlikely() for better branch prediction * Various small cleanups * Much improved interrupt mitigation * Much improved throughput (02/03/15 1.474) Fix bug in at1700 net driver: RX_MODE was not set for the multicast case. Set it. Fixes multicast. (02/03/11 1.384.3.6) pcnet32 net driver updates 6/6: perform dwio reset after checking wio, otherwise some cards fail the probe, fix from Paul Mackerras (02/03/11 1.384.3.5) pcnet32 net driver updates 5/6: pcnet32_purge_tx_ring can be called from interrupt, so must use dev_kfree_skb_any, fix from Dave Engebretsen. (02/03/11 1.384.3.4) pcnet32 net driver updates 4/6: Increase device watchdog timeout, fix from Dave Engebretsen. (02/03/11 1.384.3.3) pcnet32 net driver updates 3/6: protect pcnet32_tx_timeout and pcnet32_set_multicast_list with spinlock, fix from Dave Engebretsen (02/03/11 1.384.3.2) pcnet32 net driver updates 2/6: irq could overflow unsigned char, change to unsigned int ioaddr could overflow unsigned int, change to unsigned long (02/03/11 1.384.3.1) pcnet32 net driver updates 1/6: fix leak in pci memory space on machines with IOMMUs. --------------080406040607000202030705-- From owner-netdev@oss.sgi.com Fri Mar 15 11:14:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FJE1r06925 for netdev-outgoing; Fri, 15 Mar 2002 11:14:01 -0800 Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FJDv906921 for ; Fri, 15 Mar 2002 11:13:57 -0800 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA68298 for ; Fri, 15 Mar 2002 13:09:52 -0600 Received: from d04nms93.raleigh.ibm.com (d04nms93.raleigh.ibm.com [9.67.226.76]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2FJFNq294060 for ; Fri, 15 Mar 2002 14:15:23 -0500 Importance: Normal Subject: I need sk_buff frag_list info. To: netdev@oss.sgi.com From: "Mark Wisner" Date: Fri, 15 Mar 2002 14:15:22 -0500 Message-ID: X-MIMETrack: Serialize by Router on D04NMS93/04/M/IBM(Release 5.0.8 |June 18, 2001) at 03/15/2002 02:15:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1312 Lines: 30 I am working on a change to the IBM 405 Ethernet driver. The Ethernet allows us to define buffer sizes smaller than the MTU size. If a packet comes in larger than the buffer size, it will be received across multiple buffers. The current driver is a zero copy driver, it uses buffers of the MTU size, where we allocate a SKB for each descriptor and have the descriptor buffer pointer point to the SKB's data buffer. This allows the driver to avoid memory to memory moves. I would like to implement the same zero copy but I want to use smaller buffers. I would like to have each descriptor point to the buffer area of a separate SKB. When a large packet is received and it is received into multiple SKB's. I would like to pass these multiple SKBs to the stack. I want to avoid using memcopies. I think frag_list is what I want to use. If frag_list are what I want: Will frag_list work when receiving a packet and passing it to the stack? I only see drivers using frag_list for transmit. If it will work, what functions should I use to put the multiple skb's into a frag_list? Can you point me to an example or any documentation? Any pointer will be greatly appreciated. Thanks, Mark K. Wisner Advisory Software Engineer IBM Microelectronics 3039 Cornwallis Rd RTP, NC 27709 Tel. 919-254-7191 Fax 919-543-7575 From owner-netdev@oss.sgi.com Fri Mar 15 16:35:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2G0ZrL19349 for netdev-outgoing; Fri, 15 Mar 2002 16:35:53 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2G0Zn919346 for ; Fri, 15 Mar 2002 16:35:49 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id E7F0E1E8C1; Sat, 16 Mar 2002 01:37:12 +0100 (MET) Date: Sat, 16 Mar 2002 01:37:12 +0100 From: Andi Kleen To: Mark Wisner Cc: netdev@oss.sgi.com Subject: Re: I need sk_buff frag_list info. Message-ID: <20020316013712.A10179@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1329 Lines: 27 On Fri, Mar 15, 2002 at 02:15:22PM -0500, Mark Wisner wrote: > I am working on a change to the IBM 405 Ethernet driver. The Ethernet What is an IBM 405? > allows us to define buffer sizes smaller than the MTU size. If a packet > comes in larger than the buffer size, it will be received across multiple > buffers. The current driver is a zero copy driver, it uses buffers of the > MTU size, where we allocate a SKB for each descriptor and have the > descriptor buffer pointer point to the SKB's data buffer. This allows the > driver to avoid memory to memory moves. > I would like to implement the same zero copy but I want to use smaller > buffers. I would like to have each descriptor point to the buffer area of a > separate SKB. When a large packet is received and it is received into > multiple SKB's. I would like to pass these multiple SKBs to the stack. I > want to avoid using memcopies. I think frag_list is what I want to use. Only when you don't want to support TCP. TCP will always reallocate and copy list linked packets currently. frag_list is purely a hack to handle fragmented packets for UDP and RAW. Instead you should use the skb data array (skb_shinfo()->frags) and fill it with page sized chunks. Documentation on how to use that is unfortunately a bit scarce, you'll need to do some RTFS. -Andi From owner-netdev@oss.sgi.com Fri Mar 15 16:46:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2G0k6U19520 for netdev-outgoing; Fri, 15 Mar 2002 16:46:06 -0800 Received: from acmay.homeip.net (IDENT:qmailr@24-25-196-177.san.rr.com [24.25.196.177]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2G0k3919516 for ; Fri, 15 Mar 2002 16:46:03 -0800 Received: (qmail 1113 invoked by uid 500); 16 Mar 2002 00:47:21 -0000 Date: Fri, 15 Mar 2002 16:47:21 -0800 From: andrew may To: Andi Kleen Cc: Mark Wisner , netdev@oss.sgi.com Subject: Re: I need sk_buff frag_list info. Message-ID: <20020315164721.A1097@ecam.san.rr.com> References: <20020316013712.A10179@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <20020316013712.A10179@wotan.suse.de> Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1046 Lines: 25 On Sat, Mar 16, 2002 at 01:37:12AM +0100, Andi Kleen wrote: > On Fri, Mar 15, 2002 at 02:15:22PM -0500, Mark Wisner wrote: > > I am working on a change to the IBM 405 Ethernet driver. The Ethernet > > What is an IBM 405? An embedded PPC chip, with the ethernet built into the chip. > Only when you don't want to support TCP. TCP will always reallocate and copy > list linked packets currently. > frag_list is purely a hack to handle fragmented packets for UDP and RAW. > > Instead you should use the skb data array (skb_shinfo()->frags) and fill > it with page sized chunks. > Documentation on how to use that is unfortunately a bit scarce, you'll need > to do some RTFS. Well I still have not seen any ethernet card do this. Even though it seems that the hardware would support it. This could be a big help for jumbo frames with GigE. So if you suggest to use ->frags should the skb->data be left alone? I can see no way off knowing ahead of time wether the ptr's giving to hardware for a rx will be used for the start of a packet. From owner-netdev@oss.sgi.com Fri Mar 15 16:53:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2G0rD919850 for netdev-outgoing; Fri, 15 Mar 2002 16:53:13 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2G0rB919847 for ; Fri, 15 Mar 2002 16:53:11 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 779551E985; Sat, 16 Mar 2002 01:54:34 +0100 (MET) Date: Sat, 16 Mar 2002 01:54:34 +0100 From: Andi Kleen To: andrew may Cc: Andi Kleen , Mark Wisner , netdev@oss.sgi.com Subject: Re: I need sk_buff frag_list info. Message-ID: <20020316015434.A14820@wotan.suse.de> References: <20020316013712.A10179@wotan.suse.de> <20020315164721.A1097@ecam.san.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020315164721.A1097@ecam.san.rr.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 429 Lines: 9 On Fri, Mar 15, 2002 at 04:47:21PM -0800, andrew may wrote: > So if you suggest to use ->frags should the skb->data be left alone? > I can see no way off knowing ahead of time wether the ptr's giving to > hardware for a rx will be used for the start of a packet. The headers should be in skb->data if possible. If not the stack will do some copying. So you could put some arbitary first fragment (e.g. 128 bytes) there. -Andi From owner-netdev@oss.sgi.com Sat Mar 16 07:51:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GFpGR06433 for netdev-outgoing; Sat, 16 Mar 2002 07:51:16 -0800 Received: from hotmail.com (f146.law15.hotmail.com [64.4.23.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2GFpB906430 for ; Sat, 16 Mar 2002 07:51:12 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Mar 2002 07:52:35 -0800 Received: from 80.2.247.245 by lw15fd.law15.hotmail.msn.com with HTTP; Sat, 16 Mar 2002 15:52:35 GMT X-Originating-IP: [80.2.247.245] From: "Arthur Scherbius" To: netdev@oss.sgi.com Cc: davem@redhat.com, ak@muc.de, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi Subject: kernel support for l2tp Date: Sat, 16 Mar 2002 15:52:35 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2002 15:52:35.0787 (UTC) FILETIME=[9776F9B0:01C1CD02] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 934 Lines: 24 I have a 2.4.x kernel with l2tp support interworking with a cisco box. Would there be any interest in putting it into the kernel distribution ? The kernel driver takes ip_gre.c and ppp_async.c as the starting point for the code. Thus the driver writes to the ppp_channel.h interface. It then suppports the pppoe model of operation for terminating l2tp sessions with ppp i.e. in response to pppd ioctls it indicates l2tp session packets at ppp_input(). The l2tp daemon is a modified version of the Bill Baumann sourceforge project. The daemon forks the 2.4 pppd with a new plugin (pppol2tp) to orchestrate the terminaton of ppp sessions. Tunnels can be added/deleted using a modified version of iproute2 ip tunnel add/del. Let me know if you want to pursue this further. Arthur _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-netdev@oss.sgi.com Sat Mar 16 09:15:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GHFXb08746 for netdev-outgoing; Sat, 16 Mar 2002 09:15:33 -0800 Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2GHFU908743 for ; Sat, 16 Mar 2002 09:15:30 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org ident=mail) by coruscant.gnumonks.org with esmtp (Exim 3.33 #1) id 16mHnb-0008Rt-00; Sat, 16 Mar 2002 18:16:55 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 3.34 #1) id 16mHlX-00048Y-00; Sat, 16 Mar 2002 18:14:47 +0100 Date: Sat, 16 Mar 2002 18:14:47 +0100 From: Harald Welte To: "Arthur Scherbius" Cc: netdev@oss.sgi.com Subject: Re: kernel support for l2tp Message-ID: <20020316181447.B31449@sunbeam.de.gnumonks.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from arthur_scherbius@hotmail.com on Sat, Mar 16, 2002 at 03:52:35PM +0000 X-Operating-System: Linux sunbeam.de.gnumonks.org 2.4.17 X-Date: Today is Setting Orange, the 70th day of Chaos in the YOLD 3168 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 851 Lines: 22 On Sat, Mar 16, 2002 at 03:52:35PM +0000, Arthur Scherbius wrote: > > I have a 2.4.x kernel with l2tp support interworking with a cisco box. Would > there be any interest in putting it into the kernel distribution ? This sounds definitely interesting. I'm not one of the linux networking gods, so I can't tell you anything about kernel inclusion. But even if your l2tp kernel module doesn't get into the mainstream kernel, you definitely should publish the source somewhere, so other people can use it. > Arthur -- Live long and prosper - Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*) From owner-netdev@oss.sgi.com Sat Mar 16 18:36:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2H2aHE18197 for netdev-outgoing; Sat, 16 Mar 2002 18:36:17 -0800 Received: from localhost.localdomain (dsl092-219-020.nyc1.dsl.speakeasy.net [66.92.219.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2H2aB918194 for ; Sat, 16 Mar 2002 18:36:11 -0800 Received: from localhost (becker@localhost) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id WAA03128; Fri, 15 Mar 2002 22:44:27 -0500 X-Authentication-Warning: localhost.localdomain: becker owned process doing -bs Date: Fri, 15 Mar 2002 22:43:12 -0500 (EST) From: Donald Becker X-X-Sender: To: Mark Wisner cc: Subject: Re: I need sk_buff frag_list info. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2617 Lines: 50 On Fri, 15 Mar 2002, Mark Wisner wrote: > I am working on a change to the IBM 405 Ethernet driver. The Ethernet > allows us to define buffer sizes smaller than the MTU size. If a packet > comes in larger than the buffer size, it will be received across multiple > buffers. The current driver is a zero copy driver, it uses buffers of the > MTU size, where we allocate a SKB for each descriptor and have the > descriptor buffer pointer point to the SKB's data buffer. This allows the > driver to avoid memory to memory moves. > I would like to implement the same zero copy but I want to use smaller > buffers. I would like to have each descriptor point to the buffer area of a > separate SKB. When a large packet is received and it is received into > multiple SKB's. I would like to pass these multiple SKBs to the stack. I > want to avoid using memcopies. I think frag_list is what I want to use. Presumably you are trying to receive into smaller chunks in an effort to save memory. If so, your goal is misguided. A significant part of the work in receiving packets is handling the skbuffer allocation. By receiving large packets into multiple buffers, you multiply that work. The overhead in setting up and following multiple descriptors is also significant: descriptors might be much more costly to access than normally cached memory since descriptors are alternately accessed by the NIC and CPU. Using multiple descriptors and buffers per packet will also make the PCI bus utilization much worse. A modern PCI v2.1 NIC can write a received Ethernet packet in a single linear burst. With multiple descriptors and buffers the NIC must alternate between reading descriptors and writing the data, re-arbitrating many times for a large packet. Consider also that there is very little reduction in memory use when using small buffers. Packets have bimodal size distribution correlated with potential persistence: Packets are either small (e.g. acks) or full sized (data). The small packets are quickly handled, while the full sized packets are the ones that hang around waiting for the data to be consumed. A final related note: drivers should always allocate consistently sized skbuffs. Specifically, Ethernet drivers should always allocate 1536 byte buffers. Using a single buffer size gives the skbuff allocator the opportunity to efficiently recycle buffers rather than having to allocate and free a mix of sizes. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Sun Mar 17 01:58:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2H9wDO25682 for netdev-outgoing; Sun, 17 Mar 2002 01:58:13 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2H9w5925678 for ; Sun, 17 Mar 2002 01:58:06 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 293841E13B; Sun, 17 Mar 2002 10:59:29 +0100 (MET) Date: Sun, 17 Mar 2002 10:59:28 +0100 From: Andi Kleen To: Donald Becker Cc: Mark Wisner , netdev@oss.sgi.com Subject: Re: I need sk_buff frag_list info. Message-ID: <20020317105928.A15784@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 653 Lines: 14 On Fri, Mar 15, 2002 at 10:43:12PM -0500, Donald Becker wrote: > A final related note: drivers should always allocate consistently > sized skbuffs. Specifically, Ethernet drivers should always allocate > 1536 byte buffers. Using a single buffer size gives the skbuff > allocator the opportunity to efficiently recycle buffers rather than > having to allocate and free a mix of sizes. The current skbuff allocator uses kmalloc for the data part. kmalloc currently always rounds to a power of two. So for any 2K>=value+sizeof(struct skb_shared_info)>1K you will get a 2K buffer. The skbuff head recycling works independently of the data size. -Andi From owner-netdev@oss.sgi.com Sun Mar 17 11:01:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2HJ1qA05684 for netdev-outgoing; Sun, 17 Mar 2002 11:01:52 -0800 Received: from tsmtp1.mail.isp (mailhost.teleline.es [195.235.113.141] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2HJ1k905678 for ; Sun, 17 Mar 2002 11:01:48 -0800 Received: from mitra.terra.es ([193.153.115.66]) by tsmtp1.mail.isp (Netscape Messaging Server 4.15 tsmtp1 Jul 26 2001 13:10:38) with ESMTP id GT4SX600.KV5 for ; Sun, 17 Mar 2002 20:03:06 +0100 Message-Id: <5.1.0.14.2.20020317194944.00bc6940@pop3.terra.es> X-Sender: fernando.anton.terra.es@pop3.terra.es X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Mar 2002 20:02:55 +0100 To: netdev@oss.sgi.com From: Fernando Anton Subject: Kernel Packet filter and 68 bytes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1142 Lines: 28 Hi all, I have a simple question for people who has worked any time with PF_PACKET without using libpcap to capture the packets (I also need sending over the sockets, so it would not help me too much using libpcap). After opening a PF_PACKET socket with no setsockopt or ioctl operations, I get only 68 bytes for each packet (I do not use MSG_TRUNC int the recvfrom call) and I do get the real size of each packet returned from the call. I've looked over the libpcap sources and I've found that they state that there is any problem with the kernel filter which always returns 68 bytes by default. Well, it looks true for me, I only get 68 bytes for each packet, but I want the full one and I want to know if there is any easy way to tell it to the kernel (just any setsockopt or ioctl to bypass the kernel filters). If there is not such an option.. where should I touch (what kernel files more or less) to implement this option ? Thanks in advance Sorry if this question was asked before here, but I did not found any other place to ask this. Thaks for indulgence. Un saludo: Fernando Anton Alonso aka Mitra / Spanish Lords From owner-netdev@oss.sgi.com Mon Mar 18 04:33:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ICXOo26092 for netdev-outgoing; Mon, 18 Mar 2002 04:33:24 -0800 Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ICXF926088 for ; Mon, 18 Mar 2002 04:33:17 -0800 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA26144; Mon, 18 Mar 2002 06:29:05 -0600 Received: from d04nms93.raleigh.ibm.com (d04nms93.raleigh.ibm.com [9.67.226.76]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2ICYeI209428; Mon, 18 Mar 2002 07:34:40 -0500 Importance: Normal Subject: Re: I need sk_buff frag_list info. To: acmay@acmay.homeip.net Cc: ak@suse.de, netdev@oss.sgi.com From: "Mark Wisner" Date: Mon, 18 Mar 2002 07:34:39 -0500 Message-ID: X-MIMETrack: Serialize by Router on D04NMS93/04/M/IBM(Release 5.0.8 |June 18, 2001) at 03/18/2002 07:34:40 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2374 Lines: 60 I'll try to be a little more clear on what I need to do. The hardware has a size limit to a single buffer of 4K. It also has a receive buffer size register. If I wanted to receive a 9K packet, JUMBO, I could define a receive buffer size of 4k. If a packet came in that was 9K It would fill three buffers. If a 64Byte packet came in, it would use 1 of the 4K buffers. We can determine how many buffers are being used by "first" & "last" bits in the descriptor. The first 4K of the packet, Ethernet and IP header, will be in the first buffer and the FCS will be in the last buffer. I know netif_rx() expects an SKB with all the data in one contiguous buffer. I want to avoid the overhead of an additional memcpy() in the device driver, just to put the packet into a contiguous buffer. I would like to allocate receive SKBs with a 4K buffer in each. If a packet comes in that uses more than 1 SKB/buffer, I would like to link the additional SKBs to the first one and send it up with netif_rx(). This is an extreme case but it also has applications when handling smaller packets. For example, many embedded applications are memory constrained. If an application developer knows most of the Ethernet traffic is less than 512 bytes, he/she would want to allocate 512 Byte buffers. If a larger than 512 byte packet comes in, it would be received over multiple buffers. If it is correct , Linux will in reality only allocate buffers of multiples of 2K, this may be inefficient and it could put Linux at a disadvantage when competing against other embedded OSs. Andi, what is "RTFS"? Mark K. Wisner Advisory Software Engineer IBM Microelectronics 3039 Cornwallis Rd RTP, NC 27709 Tel. 919-254-7191 Fax 919-543-7575 Andi Kleen on 03/15/2002 07:54:34 PM To: andrew may cc: Andi Kleen , Mark Wisner/Raleigh/IBM@IBMUS, netdev@oss.sgi.com Subject: Re: I need sk_buff frag_list info. On Fri, Mar 15, 2002 at 04:47:21PM -0800, andrew may wrote: > So if you suggest to use ->frags should the skb->data be left alone? > I can see no way off knowing ahead of time wether the ptr's giving to > hardware for a rx will be used for the start of a packet. The headers should be in skb->data if possible. If not the stack will do some copying. So you could put some arbitary first fragment (e.g. 128 bytes) there. -Andi From owner-netdev@oss.sgi.com Mon Mar 18 04:44:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ICiXl26321 for netdev-outgoing; Mon, 18 Mar 2002 04:44:33 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ICiR926318 for ; Mon, 18 Mar 2002 04:44:27 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id ED2F41E880; Mon, 18 Mar 2002 13:45:49 +0100 (MET) Date: Mon, 18 Mar 2002 13:45:49 +0100 From: Andi Kleen To: Mark Wisner Cc: netdev@oss.sgi.com Subject: Re: I need sk_buff frag_list info. Message-ID: <20020318134549.A27606@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2262 Lines: 48 On Mon, Mar 18, 2002 at 07:34:39AM -0500, Mark Wisner wrote: > I know netif_rx() expects an SKB with all the data in one contiguous > buffer. I want to avoid the overhead of an additional memcpy() in the In 2.4 it doesn't anymore, but only some networking protocols support it (TCP/UDP/RAW). The others just always fallback to copying if they cannot deal with a multi paged skb. > I would like to allocate receive SKBs with a 4K buffer in each. If a > packet comes in that uses more than 1 SKB/buffer, I would like to link the > additional SKBs to the first one and send it up with netif_rx(). This should work with a paged skb. As a warning it is not a very common use case though, there are few if any drivers that do it. So the stack should support it, but it may not be the best tested path in the stack. > This is an extreme case but it also has applications when handling smaller > packets. For example, many embedded applications are memory constrained. If > an application developer knows most of the Ethernet traffic is less than > 512 bytes, he/she would want to allocate 512 Byte buffers. If a larger than > 512 byte packet comes in, it would be received over multiple buffers. > > If it is correct , Linux will in reality only allocate buffers of multiples > of 2K, this may be inefficient and it could put Linux at a disadvantage > when competing against other embedded OSs. No Linux doesn't allocate buffers only in multiple of 2Ks. It just currently rounds buffer sizes to the next power of two. You can easily change it by changing the kmalloc size array in mm/slab.c. It just usually doesn't buy you much because the fundamental unit is the hardware page size, normally 4K, and e.g. when you define a 1.5K kmalloc size it doesn't fit very well into 4K and requires multipage allocations which has its own problems. For smaller sizes that fit better into 4K you can add it if the rounding to power of two is a big problem for you (the power of two sizes are not any inherent properties of the allocator, it can work with any sizes, just a somewhat stupid default list that should be probably changed. Tuning it for specific embedded applications makes definitely sense.) > > Andi, what is "RTFS"? Read the Fine Source. -Andi From owner-netdev@oss.sgi.com Mon Mar 18 21:11:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J5Bno18284 for netdev-outgoing; Mon, 18 Mar 2002 21:11:49 -0800 Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J5Bk918280 for ; Mon, 18 Mar 2002 21:11:46 -0800 Received: from VAIOHE (dhcp79.docomolabs-usa.com [172.21.96.79]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with ESMTP id g2J5D9I24502 for ; Mon, 18 Mar 2002 21:13:09 -0800 (PST) Reply-To: From: "Xiaoning He" To: Subject: Delete an existing IPv6 address Date: Mon, 18 Mar 2002 21:11:26 -0800 Organization: NTT-Docomo USA Labs Message-ID: <000001c1cf04$888b1680$4f6015ac@VAIOHE> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20020318134549.A27606@wotan.suse.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 531 Lines: 18 Hi All While I am modifying the IPv6 kernel, I need to delete an exiting IP address when it is necessary. I have to questions, could anyone please to help me out? 1. Is the IPv6 address has a lifetime associated with it? It seems after a router advertisement is received, the address will be there forever. 2. How to remove this address? Is there any code available showing how to program in the kernel to remove the address? What functions should I use and how to use them? Thank you very much for your helps. Xiaoning He From owner-netdev@oss.sgi.com Tue Mar 19 13:37:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JLbND06965 for netdev-outgoing; Tue, 19 Mar 2002 13:37:23 -0800 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JLbI906962 for ; Tue, 19 Mar 2002 13:37:18 -0800 Received: (qmail 15233 invoked from network); 19 Mar 2002 21:38:40 -0000 Received: from pd950fce0.dip.t-dialin.net (HELO ??) (217.80.252.224) by mail.bieringer.de with SMTP; 19 Mar 2002 21:38:40 -0000 Date: Tue, 19 Mar 2002 22:38:39 +0100 From: Peter Bieringer To: xiaoning@docomolabs-usa.com, netdev@oss.sgi.com Subject: Re: Delete an existing IPv6 address Message-ID: <23160000.1016573919@localhost> In-Reply-To: <000001c1cf04$888b1680$4f6015ac@VAIOHE> References: <000001c1cf04$888b1680$4f6015ac@VAIOHE> X-Mailer: Mulberry/2.2.0b3 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 775 Lines: 26 --On Monday, March 18, 2002 09:11:26 PM -0800 Xiaoning He wrote: > While I am modifying the IPv6 kernel, I need to delete an exiting IP > address when it is necessary. > > I have to questions, could anyone please to help me out? > > 1. Is the IPv6 address has a lifetime associated with it? It seems > after a router advertisement is received, the address will be there > forever. Depends on distributed lifetime sent with the advertisement. Using radvd the default is very high, but can be set by config. > 2. How to remove this address? Is there any code available showing > how to program in the kernel to remove the address? What functions > should I use and how to use them? Use tool "ip", see IPv6 howto for more Peter From owner-netdev@oss.sgi.com Tue Mar 19 16:22:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K0MDG11213 for netdev-outgoing; Tue, 19 Mar 2002 16:22:13 -0800 Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2K0MA911210 for ; Tue, 19 Mar 2002 16:22:10 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2K0NRO15762 for ; Wed, 20 Mar 2002 00:23:27 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2K0EVY17623 for ; Wed, 20 Mar 2002 00:14:31 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031916171800534 for ; Tue, 19 Mar 2002 16:17:18 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 16:13:52 -0800 Message-ID: From: "Hossain, Mohammad" To: "'netdev@oss.sgi.com'" Subject: Bug in SUN's solaris? Date: Tue, 19 Mar 2002 16:13:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 578 Lines: 19 Hello, I have an application which sends and receives multiple IPv6 extension headers. I can send and receive single IPv6 extension header per IPv6 packet in Solaris and Linux. I can send multiple IPv6 extension headers in the same IPv6 packet in Solaris BUT I can't receive them. I only get the first extension header in the packet (HopByHop) in Solaris. However, in Linux I get all extension headers in the same IPv6 data packet. Is it a bug in SUN's implementation of IPv6 raw support? Has anybody done it? or faced it? Thanks. Arif From owner-netdev@oss.sgi.com Thu Mar 21 09:35:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHZQm02320 for netdev-outgoing; Thu, 21 Mar 2002 09:35:26 -0800 Received: from localhost.localdomain (battlejitney.wdhq.scyld.com [216.254.93.178]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LHZKq02317 for ; Thu, 21 Mar 2002 09:35:20 -0800 Received: from localhost (becker@localhost) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id MAA01004; Mon, 18 Mar 2002 12:39:37 -0500 Date: Mon, 18 Mar 2002 12:39:37 -0500 (EST) From: Donald Becker X-X-Sender: To: Andi Kleen cc: Mark Wisner , Subject: Re: I need sk_buff frag_list info. In-Reply-To: <20020317105928.A15784@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2556 Lines: 52 On Sun, 17 Mar 2002, Andi Kleen wrote: > On Fri, Mar 15, 2002 at 10:43:12PM -0500, Donald Becker wrote: > > A final related note: drivers should always allocate consistently > > sized skbuffs. Specifically, Ethernet drivers should always allocate > > 1536 byte buffers. Using a single buffer size gives the skbuff > > allocator the opportunity to efficiently recycle buffers rather than > > having to allocate and free a mix of sizes. > > The current skbuff allocator uses kmalloc for the data part. kmalloc > currently always rounds to a power of two. So for any > 2K>=value+sizeof(struct skb_shared_info)>1K > you will get a 2K buffer. The skbuff head recycling works independently > of the data size. I sure Andi noticed the wording, but for others that didn't: I wrote: "the opportunity", which the current implementation doesn't take advantage of. There have been prototype allocator implementations that recycled skbuff data areas, and keeping the drivers implementations consistent will make it easier for this type optimization to be done. Memory allocators are important for performance, and must be frequently re-tuned as systems evolved with new cache structures and memory use. Keeping the job of the memory allocator simple is critical, as allocators can have a surprisingly bad effect on performance. Not only can they to have much worse performance than their memory access count indicates because of cache effects, the resulting cache flushing slows down unrelated code in ways that are difficult to measure. A bit of history on packet size: The selection of 1500 (1518) byte packets for Ethernet is somewhat awkward for allocators. The size was selected back in the days when 3Mbps Ethernet was being designed. Memory was handled in 256 byte units, and the primary considerations were access latency (helped by a small packet size), network physical span and having a packet size large enough to be handled efficiently. The selection of 9KB for jumbo packets was set by the size of inexpensive static RAM chips in the mid-80's. Seriously. That was hardware constraint that caused the early Sun 68K machines to be designed with a 8KB page size instead of a VAX-like 4KB page size. That caused the de facto standard NFS block size to be 8KB, which was later the motivation for selecting 9KB for jumbo packets over the other proposed sizes. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Thu Mar 21 09:42:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHgUN02519 for netdev-outgoing; Thu, 21 Mar 2002 09:42:30 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LHgQq02515 for ; Thu, 21 Mar 2002 09:42:27 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 4C4DB1E4BA; Thu, 21 Mar 2002 17:42:19 +0100 (MET) Date: Thu, 21 Mar 2002 17:42:19 +0100 From: Andi Kleen To: Donald Becker Cc: netdev@oss.sgi.com Subject: Re: I need sk_buff frag_list info. Message-ID: <20020321174219.A26613@wotan.suse.de> References: <20020317105928.A15784@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1335 Lines: 27 On Mon, Mar 18, 2002 at 12:39:37PM -0500, Donald Becker wrote: > Memory allocators are important for performance, and must be frequently > re-tuned as systems evolved with new cache structures and memory use. > Keeping the job of the memory allocator simple is critical, as > allocators can have a surprisingly bad effect on performance. Not only > can they to have much worse performance than their memory access > count indicates because of cache effects, the resulting cache flushing > slows down unrelated code in ways that are difficult to measure. I fully agree. I played with this a few years ago with slab (you can still see the commented out skb_add_mtu() function in skbuff.c), but it didn't help much with 4K pages. Now with 8K page sizes becomming more common that changes of course. The standard power of two spacing of the slab kmalloc is IMHO very stupid. I think one of the later slab papers from Sun even noted that power of two is the worst packing for many cases. There must be surely a better list of values that would better for many workloads (not for 1.5K ethernet on 4K, but for other things) 9k jumbo frames have the same problem unfortunately, you cannot pack two into a 16K double page, which is always allocated. > > A bit of history on packet size: Thanks for the interesting history lesson. -Andi From owner-netdev@oss.sgi.com Thu Mar 21 10:57:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LIvfF07905 for netdev-outgoing; Thu, 21 Mar 2002 10:57:41 -0800 Received: from mail.gmx.net (sproxy.gmx.net [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LIvaq07899 for ; Thu, 21 Mar 2002 10:57:36 -0800 Received: (qmail 6671 invoked by uid 0); 21 Mar 2002 17:57:27 -0000 Received: from a1as19-p21.stg.tli.de (HELO havana.yon.net) (195.252.194.21) by mail.gmx.net (mp008-rz3) with SMTP; 21 Mar 2002 17:57:27 -0000 Received: from localhost (localhost [127.0.0.1]) by havana.yon.net (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g2LHuA024648 for ; Thu, 21 Mar 2002 18:56:10 +0100 Date: Thu, 21 Mar 2002 18:56:10 +0100 (CET) From: Yon Uriarte Reply-To: To: Subject: sock_queue_rcv_skb skb->dev = NULL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1283 Lines: 32 Hi, I'm developing support for UDP encapsulated ESP packets for freeswan, for an easier NAT traversal. Check the drafts at ietf.org. I've changed sock->data_ready() on the 'interesting' sockets to avoid touching my code on most cases. Then I check the skb, dequeueing it and adjusting it to pass it on to freeswan as a normal ESP packet. But then ipsec_rcv needs skb->dev, to find the incoming device and the matching ipsecXXX interface. If it doesnt find a skb->dev it still passes it on, which seems to heavily kill my uml 'machine' (gdb is running, but the kernel just dies with some trap) upon calling netif_rx on the dev'less skb (so the decrypted skb seems to be received on the ipsecXXX interfaces and you can account it, etc.). I commented out the skb->dev = NULL; line and it seems to work but I'm not comfortable at all with this. First because I dont know what if anything I've just broken and because it means a kernel recompile and reboot is needed, which is against one of my goals, support for compiling modular freeswan with just the kernel sources, no need to reboot. Can someone enlighten me on the need to NULL'ify skb->dev upon sock queueing? And can the kernel run with that line commented out? It does now, but that means nothing. TIA, HAND yon From owner-netdev@oss.sgi.com Thu Mar 21 11:19:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJJoc08724 for netdev-outgoing; Thu, 21 Mar 2002 11:19:50 -0800 Received: from web13303.mail.yahoo.com (web13303.mail.yahoo.com [216.136.175.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJJhq08718 for ; Thu, 21 Mar 2002 11:19:44 -0800 Message-ID: <20020321181942.35576.qmail@web13303.mail.yahoo.com> Received: from [62.96.207.14] by web13303.mail.yahoo.com via HTTP; Thu, 21 Mar 2002 10:19:42 PST Date: Thu, 21 Mar 2002 10:19:42 -0800 (PST) From: Joerg Pommnitz Subject: Bad interaction of SO_BINDTODEVICE and ARP in Linux 2.4.10 To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1947 Lines: 58 On the advise of a coworker I'm resending this message with a more sexy Subject line. The previous one did sound too newbieish... Hi List, I have the following setup: One host with two interfaces (eth0, eth1): eth0 Link encap:Ethernet HWaddr 00:E0:4C:71:05:92 inet addr:10.1.12.87 Bcast:10.1.12.255 Mask:255.255.255.0 inet6 addr: fe80::2e0:4cff:fe71:592/10 Scope:Link UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:4512 errors:0 dropped:0 overruns:0 frame:0 TX packets:4034 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:345507 (337.4 Kb) TX bytes:407841 (398.2 Kb) Interrupt:11 Base address:0x5000 eth1 Link encap:Ethernet HWaddr 00:E0:4C:71:05:91 inet addr:10.1.12.151 Bcast:10.1.12.255 Mask:255.255.255.0 inet6 addr: fe80::2e0:4cff:fe71:591/10 Scope:Link UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:2709 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:239132 (233.5 Kb) TX bytes:2646 (2.5 Kb) Interrupt:10 Base address:0x7000 when I do ping -I eth0 10.1.12.151 I don't get a reply but ARP requests like this: 19:23:59.219402 arp who-has 10.1.12.151 tell 10.1.12.87 19:24:00.219402 arp who-has 10.1.12.151 tell 10.1.12.87 19:24:01.219402 arp who-has 10.1.12.151 tell 10.1.12.87 19:24:02.219402 arp who-has 10.1.12.151 tell 10.1.12.87 So the host tries to resolve its own MAC address and does not answer itself. Manually setting the ARP entry fails as well. Question: Should this work at all? If yes, is there a fix? Regards Jörg ===== -- Regards Joerg __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From owner-netdev@oss.sgi.com Thu Mar 21 11:47:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJlXj09423 for netdev-outgoing; Thu, 21 Mar 2002 11:47:33 -0800 Received: from web13308.mail.yahoo.com (web13308.mail.yahoo.com [216.136.175.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJlRq09418 for ; Thu, 21 Mar 2002 11:47:27 -0800 Message-ID: <20020321184724.70917.qmail@web13308.mail.yahoo.com> Received: from [62.96.207.14] by web13308.mail.yahoo.com via HTTP; Thu, 21 Mar 2002 10:47:24 PST Date: Thu, 21 Mar 2002 10:47:24 -0800 (PST) From: Joerg Pommnitz Subject: Re: Bad interaction of SO_BINDTODEVICE and ARP in Linux 2.4.10 To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1388 Lines: 43 Hi Lists, I worked around my previous problem by deleting the routing entry that sent packets for my subnet directly to their destination. Using our default router works (somewhat). I can now see the ICMP packets on eth1: jpo> /sbin/ifconfig -a eth0 Link encap:Ethernet HWaddr 00:E0:4C:71:05:92 inet addr:10.1.12.87 Bcast:10.1.12.255 Mask:255.255.255.0 eth1 Link encap:Ethernet HWaddr 00:E0:4C:71:05:91 inet addr:10.1.12.151 Bcast:10.1.12.255 Mask:255.255.255.0 jpo> netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.1.12.1 0.0.0.0 UG 40 0 0 eth0 jpo> ping -I eth0 10.1.12.151 jpo> sudo /usr/sbin/tcpdump -i eth1 host 10.1.12.151 -n tcpdump: listening on eth1 20:40:46.289402 10.1.12.87 > 10.1.12.151: icmp: echo request (DF) 20:40:47.289402 10.1.12.87 > 10.1.12.151: icmp: echo request (DF) 20:40:48.289402 10.1.12.87 > 10.1.12.151: icmp: echo request (DF) 20:40:49.289402 10.1.12.87 > 10.1.12.151: icmp: echo request (DF) 20:40:50.289402 10.1.12.87 > 10.1.12.151: icmp: echo request (DF) It seems that no answer is sent at all. Any ideas? Regards Jörg ===== -- Regards Joerg __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From owner-netdev@oss.sgi.com Thu Mar 21 17:31:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M1Vbg28805 for netdev-outgoing; Thu, 21 Mar 2002 17:31:37 -0800 Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M1VZq28802 for ; Thu, 21 Mar 2002 17:31:36 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2M1WhG05288 for ; Fri, 22 Mar 2002 01:32:43 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2M1Wo317034 for ; Fri, 22 Mar 2002 01:32:50 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002032117332227603 for ; Thu, 21 Mar 2002 17:33:22 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 17:33:57 -0800 Message-ID: From: "Hossain, Mohammad" To: netdev@oss.sgi.com Subject: A small question Date: Thu, 21 Mar 2002 17:33:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 299 Lines: 11 Hello there, I have a small question: How to know the local interface (index, interface address) on which a Raw packet was received in Solaris? I am able to do it in Linux using IP_PKTINFO socket option. But this socket option is not available in Solaris. Have nice time. Thanks Arif From owner-netdev@oss.sgi.com Thu Mar 21 23:33:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M7Xdo09457 for netdev-outgoing; Thu, 21 Mar 2002 23:33:39 -0800 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M7XYq09451 for ; Thu, 21 Mar 2002 23:33:35 -0800 Received: (qmail 22442 invoked from network); 22 Mar 2002 07:35:51 -0000 Received: from p50805609.dip.t-dialin.net (HELO ??) (80.128.86.9) by mail.bieringer.de with SMTP; 22 Mar 2002 07:35:51 -0000 Date: Fri, 22 Mar 2002 08:35:50 +0100 From: Peter Bieringer To: Maillist netdev Subject: Support of icmp-mask-requests gone in current Linux kernels Message-ID: <15450000.1016782550@localhost> X-Mailer: Mulberry/2.2.0b3 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 791 Lines: 30 Hi, a college ask me why the icmp-mask-request support of current Linux kernels is no longer available. Some hints about the "why removed" are in "net/ipv4/icmp.c". Unfortunately, ANK's comment matches not all cases: ..."It is wrong, it is obsolete, nobody uses it in any case. --ANK"... For creating a Jumpstart server for Sun Solaris they are needed. His scenario: IPv4 address range: 10.10.0.0/16 Booting Solaris sends via rpc.bootparamd a icmp-mask-request which isn't answered. Now Solaris is using 10.255.255.255 as broadcast address, which isn't nice indeed. Can someone point me to proper patches for current 2.2.x or 2.4.x versions. Or is it possible to catch such requests in user-space (perhaps with 2.4.x using netfilter)? Thank you very much for help, Peter From owner-netdev@oss.sgi.com Fri Mar 22 02:11:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MAB1j14828 for netdev-outgoing; Fri, 22 Mar 2002 02:11:01 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MAAvq14825 for ; Fri, 22 Mar 2002 02:10:57 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id AAFEF1E0C3; Fri, 22 Mar 2002 11:13:15 +0100 (MET) Date: Fri, 22 Mar 2002 11:13:15 +0100 From: Andi Kleen To: Peter Bieringer Cc: Maillist netdev Subject: Re: Support of icmp-mask-requests gone in current Linux kernels Message-ID: <20020322111315.A3828@wotan.suse.de> References: <15450000.1016782550@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15450000.1016782550@localhost> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 300 Lines: 12 > Can someone point me to proper patches for current 2.2.x or 2.4.x > versions. I'm not aware of any patches for it. > > Or is it possible to catch such requests in user-space (perhaps with > 2.4.x using netfilter)? You can catch them just using normal raw sockets, no need for netfilter. -Andi From owner-netdev@oss.sgi.com Fri Mar 22 04:34:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MCYfj19895 for netdev-outgoing; Fri, 22 Mar 2002 04:34:41 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MCYZq19892 for ; Fri, 22 Mar 2002 04:34:35 -0800 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id NAA23147; Fri, 22 Mar 2002 13:41:09 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15515.9829.101250.477385@robur.slu.se> Date: Fri, 22 Mar 2002 13:41:09 +0100 To: Andi Kleen Cc: Donald Becker , netdev@oss.sgi.com Subject: Re: I need sk_buff frag_list info. In-Reply-To: <20020321174219.A26613@wotan.suse.de> References: <20020317105928.A15784@wotan.suse.de> <20020321174219.A26613@wotan.suse.de> X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1455 Lines: 45 Andi Kleen writes: > I fully agree. I played with this a few years ago with slab > (you can still see the commented out skb_add_mtu() function in skbuff.c), > but it didn't help much with 4K pages. Now with 8K page sizes becomming > more common that changes of course. > > The standard power of two spacing of the slab kmalloc is IMHO very stupid. > I think one of the later slab papers from Sun even noted that power of > two is the worst packing for many cases. > There must be surely a better list of values that would better for > many workloads (not for 1.5K ethernet on 4K, but for other things) > 9k jumbo frames have the same problem unfortunately, you cannot pack > two into a 16K double page, which is always allocated. Hello! Here is an related experiment with e1000 allocating different slab-sizes Originally e1000 allocates 4k slabs for ordinary 1500 MTU ethernet packets. The e1000 driver was changed to use 2k as a comparison. The forwarding path was tested with 1 Million 64 byte packets @ 1 Mpps. Kernel 2.4.16/NAPI /proc/slabinfo with orig driver size-4096 524 526 4096 524 526 1 size-2048 8 8 2048 4 4 1 /proc/slabinfo with patch for 2k size-4096 12 13 4096 12 13 1 size-2048 520 856 2048 263 428 1 slab- throughput size ------------------- 2k 34.3% 4k 32.7% Cheers. --ro From owner-netdev@oss.sgi.com Fri Mar 22 08:13:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MGDmu24861 for netdev-outgoing; Fri, 22 Mar 2002 08:13:48 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MGDhq24858 for ; Fri, 22 Mar 2002 08:13:43 -0800 Received: from pakrat by www.linux.org.uk with local (Exim 3.33 #5) id 16oRi1-0004iv-00; Fri, 22 Mar 2002 16:16:05 +0000 Date: Fri, 22 Mar 2002 16:16:05 +0000 From: Chris Dukes To: Peter Bieringer Cc: Maillist netdev Subject: Re: Support of icmp-mask-requests gone in current Linux kernels Message-ID: <20020322161605.W6003@parcelfarce.linux.theplanet.co.uk> References: <15450000.1016782550@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15450000.1016782550@localhost>; from pb@bieringer.de on Fri, Mar 22, 2002 at 08:35:50AM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1367 Lines: 41 On Fri, Mar 22, 2002 at 08:35:50AM +0100, Peter Bieringer wrote: > Hi, > > a college ask me why the icmp-mask-request support of current Linux > kernels is no longer available. > > Some hints about the "why removed" are in "net/ipv4/icmp.c". > > Unfortunately, ANK's comment matches not all cases: > > ..."It is wrong, it is obsolete, nobody uses it in any case. --ANK"... And it should be a runtime sysctl option to turn it on and off. > > > For creating a Jumpstart server for Sun Solaris they are needed. > > His scenario: > IPv4 address range: 10.10.0.0/16 > Booting Solaris sends via rpc.bootparamd a icmp-mask-request which > isn't answered. Now Solaris is using 10.255.255.255 as broadcast > address, which isn't nice indeed. > > > Can someone point me to proper patches for current 2.2.x or 2.4.x > versions. > > Or is it possible to catch such requests in user-space (perhaps with > 2.4.x using netfilter)? How much are you tied to Linux for bootparamd and the ICMP MASK reply? The BSDs still seem to offer the option of turning on ICMP MASK Reply through a sysctl. It *IS* off by default. (The question becomes do you want to write a program to detect ICMP MASK requests and form an ICMP MASK replies. Or do you want to use pre-existing code?) -- Chris Dukes "Bert is apparently EEEEVIL, whereas Oscar is just a sysadmin^Wgrouch." -- gorski From owner-netdev@oss.sgi.com Fri Mar 22 09:22:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MHMxp26173 for netdev-outgoing; Fri, 22 Mar 2002 09:22:59 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MHL4q26118 for ; Fri, 22 Mar 2002 09:21:04 -0800 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2MHNJo23156 for ; Fri, 22 Mar 2002 12:23:19 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HLCVPXWF; Fri, 22 Mar 2002 12:23:19 -0500 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQT69FC8; Fri, 22 Mar 2002 12:23:24 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 694B453FB for ; Fri, 22 Mar 2002 12:32:53 -0500 (EST) Message-ID: <3C9B6AC5.AB1ABED9@nortelnetworks.com> Date: Fri, 22 Mar 2002 12:32:53 -0500 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: any problems using read() syscall to read from raw socket? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 627 Lines: 23 I'm reading from a raw socket, and I'm trying to decide what syscall to use. In increasing order of speed, we have: read() recv() recvfrom() The options in recv and recvfrom are set to zero, and the address info in recvfrom is set to NULL. Given this, are there any problems using read() to get the packets? It seems to work fine, but I wanted to double-check. Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Sat Mar 23 08:57:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NGvDZ12894 for netdev-outgoing; Sat, 23 Mar 2002 08:57:13 -0800 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2NGv4q12891 for ; Sat, 23 Mar 2002 08:57:05 -0800 Received: (qmail 27442 invoked by uid 2001); 23 Mar 2002 16:59:21 -0000 Date: Sat, 23 Mar 2002 17:59:21 +0100 From: Petr Baudis To: Pekka Savola Cc: Jan Oravec , netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, xs26-dev@xs26.net Subject: Re: addrconf.c - possible bug Message-ID: <20020323165921.GC1954@pasky.ji.cz> Reply-To: xs26-dev@xs26.net References: <20020310030548.GA9466@hades.xs26.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.0i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2277 Lines: 52 Dear diary, on Sun, Mar 10, 2002 at 07:27:38AM CET, I got a letter, where Pekka Savola told me, that... > On Sun, 10 Mar 2002, Jan Oravec wrote: > > On Sat, Mar 09, 2002 at 08:40:17PM +0200, Pekka Savola wrote: > > > On Sat, 9 Mar 2002 kuznet@ms2.inr.ac.ru wrote: > > > > Pekka, please, reread the report; they talk about _neigbour_ _solicitations_. > > > > They have nothing to do either with ifp->probes, RS, DA or with addrconf.c > > > > at all. It is deal of ndisc.c/neghbour.c. > > > > > > Well, DAD *does* use neighbour solicitations. But the problem report was > > > indeed rather unclear; at least tcpdumps would have been nice. > > > > We hadn't log files until now, because this problem happens about once per 2-3 days. > > > > Here is example of tcpdump log... > > > > fe80::201:2ff:fedc:d28c is FreeBSD box > > fe80::3e18:401b is Linux box (2.4.18) > > > > after some time without any problem it started to answer with redirect > > instead of neighbor advertisement. > > > > #tcpdump -i gif0 -n icmp6 > > > > 04:42:40.187050 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b > > 04:42:40.223644 fe80::3e18:401b > fe80::201:2ff:fedc:d28c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b > > 04:42:40.224794 fe80::201:2ff:fedc:d28c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b > > 04:42:40.226296 fe80::201:2ff:fedc:d28c > fe80::201:2ff:fedc:d28c: icmp6: fe80::3e18:401b unreachable address > > I think I've seen something similar to this before, and IIRC it was caused by > the fact that loopback interface had been brought down. > > If loopback has been taken down and is back up, IIRC the addresses of the > interfaces must be "refreshed" (e.g. by also taking the interfaces down and > up). First, sorry for the late reply. The problem is, that we don't do anything with loopback interface at all. Please ask us for any additional informations you need, we'll gladly provide you them. -- Petr "Pasky" Baudis * elinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI hacker . Teamwork is essential -- it allows you to blame someone else. . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From owner-netdev@oss.sgi.com Sat Mar 23 09:06:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NH6Il13151 for netdev-outgoing; Sat, 23 Mar 2002 09:06:18 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2NH6Eq13148 for ; Sat, 23 Mar 2002 09:06:15 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2NH8Qx30044; Sat, 23 Mar 2002 19:08:27 +0200 Date: Sat, 23 Mar 2002 19:08:26 +0200 (EET) From: Pekka Savola To: xs26-dev@xs26.net cc: Jan Oravec , , Subject: Re: addrconf.c - possible bug In-Reply-To: <20020323165921.GC1954@pasky.ji.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 958 Lines: 23 On Sat, 23 Mar 2002, Petr Baudis wrote: > > I think I've seen something similar to this before, and IIRC it was caused by > > the fact that loopback interface had been brought down. > > > > If loopback has been taken down and is back up, IIRC the addresses of the > > interfaces must be "refreshed" (e.g. by also taking the interfaces down and > > up). > > First, sorry for the late reply. > > The problem is, that we don't do anything with loopback interface at all. > Please ask us for any additional informations you need, we'll gladly provide > you them. Perhaps zebra does. You could try stracing the appropriate processes to see whether they're doing something nasty; 'tcpdump -n -i lo' might also die if loopback is taken down and back up. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Sat Mar 23 10:42:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NIgZs14853 for netdev-outgoing; Sat, 23 Mar 2002 10:42:35 -0800 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2NIgTq14847 for ; Sat, 23 Mar 2002 10:42:29 -0800 Received: (qmail 31970 invoked by uid 2001); 23 Mar 2002 18:44:51 -0000 Date: Sat, 23 Mar 2002 19:44:51 +0100 From: Petr Baudis To: Pekka Savola Cc: xs26-dev@xs26.net, Jan Oravec , netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: addrconf.c - possible bug Message-ID: <20020323184451.GD1954@pasky.ji.cz> Reply-To: xs26-dev@xs26.net References: <20020323165921.GC1954@pasky.ji.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.0i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1462 Lines: 36 Dear diary, on Sat, Mar 23, 2002 at 06:08:26PM CET, I got a letter, where Pekka Savola told me, that... > On Sat, 23 Mar 2002, Petr Baudis wrote: > > > I think I've seen something similar to this before, and IIRC it was > > > caused by the fact that loopback interface had been brought down. > > > > > > If loopback has been taken down and is back up, IIRC the addresses of the > > > interfaces must be "refreshed" (e.g. by also taking the interfaces down > > > and up). > > > > First, sorry for the late reply. > > > > The problem is, that we don't do anything with loopback interface at all. > > Please ask us for any additional informations you need, we'll gladly > > provide you them. > > Perhaps zebra does. You could try stracing the appropriate processes to see > whether they're doing something nasty; 'tcpdump -n -i lo' might also die if > loopback is taken down and back up. I started the tcpdump there, and we'll see. However, by looking into code, we found no possibility how would zebra want to mess with loopback. Also, we discovered that just taking down and back up any ONE interface will fix this for ALL other interfaces as well. -- Petr "Pasky" Baudis * elinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI hacker . Teamwork is essential -- it allows you to blame someone else. . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From owner-netdev@oss.sgi.com Sun Mar 24 05:37:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ODbFC06416 for netdev-outgoing; Sun, 24 Mar 2002 05:37:15 -0800 Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ODYqq06389 for ; Sun, 24 Mar 2002 05:34:52 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA24469 for ; Mon, 25 Mar 2002 00:14:06 +1100 Date: Mon, 25 Mar 2002 00:14:06 +1100 (EST) From: James Morris To: netdev@oss.sgi.com Subject: [PATCH] removal of ip_route_output() for 2.5 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="550177381-301911034-1016975646=:24449" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 55340 Lines: 1262 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --550177381-301911034-1016975646=:24449 Content-Type: TEXT/PLAIN; charset=US-ASCII As ip_route_output() is deprecated, I thought it might be useful to remove it completely during the 2.5 series. A patch against 2.5.7 which does this and uses explicit calls to ip_route_output_key() instead is attached below. - James -- James Morris diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/include/net/route.h linux-2.5.7-w1/include/net/route.h --- linux-2.5.7.orig/include/net/route.h Sun Mar 24 12:26:19 2002 +++ linux-2.5.7-w1/include/net/route.h Sun Mar 24 21:03:13 2002 @@ -132,16 +132,6 @@ extern void ip_rt_get_source(u8 *src, struct rtable *rt); extern int ip_rt_dump(struct sk_buff *skb, struct netlink_callback *cb); -/* Deprecated: use ip_route_output_key directly */ -static inline int ip_route_output(struct rtable **rp, - u32 daddr, u32 saddr, u32 tos, int oif) -{ - struct rt_key key = { dst:daddr, src:saddr, oif:oif, tos:tos }; - - return ip_route_output_key(rp, &key); -} - - static inline void ip_rt_put(struct rtable * rt) { if (rt) @@ -160,14 +150,16 @@ static inline int ip_route_connect(struct rtable **rp, u32 dst, u32 src, u32 tos, int oif) { int err; - err = ip_route_output(rp, dst, src, tos, oif); + struct rt_key key = { dst:dst, src:src, tos:tos, oif:oif }; + + err = ip_route_output_key(rp, &key); if (err || (dst && src)) return err; - dst = (*rp)->rt_dst; - src = (*rp)->rt_src; + key.dst = (*rp)->rt_dst; + key.src = (*rp)->rt_src; ip_rt_put(*rp); *rp = NULL; - return ip_route_output(rp, dst, src, tos, oif); + return ip_route_output_key(rp, &key); } extern void rt_bind_peer(struct rtable *rt, int create); diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/atm/clip.c linux-2.5.7-w1/net/atm/clip.c --- linux-2.5.7.orig/net/atm/clip.c Wed Jul 4 21:27:31 2001 +++ linux-2.5.7-w1/net/atm/clip.c Sun Mar 24 20:45:54 2002 @@ -510,6 +510,7 @@ int error; struct clip_vcc *clip_vcc; struct rtable *rt; + struct rt_key key = { dst:ip, tos:1 }; if (vcc->push != clip_push) { printk(KERN_WARNING "clip_setentry: non-CLIP VCC\n"); @@ -525,7 +526,7 @@ unlink_clip_vcc(clip_vcc); return 0; } - error = ip_route_output(&rt,ip,0,1,0); + error = ip_route_output_key(&rt,&key); if (error) return error; neigh = __neigh_lookup(&clip_tbl,&ip,rt->u.dst.dev,1); ip_rt_put(rt); diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/arp.c linux-2.5.7-w1/net/ipv4/arp.c --- linux-2.5.7.orig/net/ipv4/arp.c Sun Mar 24 12:30:00 2002 +++ linux-2.5.7-w1/net/ipv4/arp.c Sun Mar 24 20:55:28 2002 @@ -350,8 +350,9 @@ struct rtable *rt; int flag = 0; /*unsigned long now; */ + struct rt_key key = { dst:sip, src:tip }; - if (ip_route_output(&rt, sip, tip, 0, 0) < 0) + if (ip_route_output_key(&rt, &key)) return 1; if (rt->u.dst.dev != dev) { NET_INC_STATS_BH(ArpFilter); @@ -893,7 +894,8 @@ r->arp_flags |= ATF_COM; if (dev == NULL) { struct rtable * rt; - if ((err = ip_route_output(&rt, ip, 0, RTO_ONLINK, 0)) != 0) + struct rt_key key = { dst:ip, tos:RTO_ONLINK }; + if ((err = ip_route_output_key(&rt, &key)) != 0) return err; dev = rt->u.dst.dev; ip_rt_put(rt); @@ -976,7 +978,8 @@ if (dev == NULL) { struct rtable * rt; - if ((err = ip_route_output(&rt, ip, 0, RTO_ONLINK, 0)) != 0) + struct rt_key key = { dst:ip, tos:RTO_ONLINK }; + if ((err = ip_route_output_key(&rt, &key)) != 0) return err; dev = rt->u.dst.dev; ip_rt_put(rt); diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/icmp.c linux-2.5.7-w1/net/ipv4/icmp.c --- linux-2.5.7.orig/net/ipv4/icmp.c Sun Mar 24 12:26:19 2002 +++ linux-2.5.7-w1/net/ipv4/icmp.c Sun Mar 24 20:56:35 2002 @@ -341,7 +341,7 @@ struct inet_opt *inet = inet_sk(sk); struct ipcm_cookie ipc; struct rtable *rt = (struct rtable*)skb->dst; - u32 daddr; + struct rt_key key = { 0 }; if (ip_options_echo(&icmp_param->replyopts, skb)) return; @@ -354,14 +354,16 @@ icmp_out_count(icmp_param->data.icmph.type); inet->tos = skb->nh.iph->tos; - daddr = ipc.addr = rt->rt_src; + key.dst = ipc.addr = rt->rt_src; ipc.opt = NULL; if (icmp_param->replyopts.optlen) { ipc.opt = &icmp_param->replyopts; if (ipc.opt->srr) - daddr = icmp_param->replyopts.faddr; + key.dst = icmp_param->replyopts.faddr; } - if (ip_route_output(&rt, daddr, rt->rt_spec_dst, RT_TOS(skb->nh.iph->tos), 0)) + key.src = rt->rt_spec_dst; + key.tos = RT_TOS(skb->nh.iph->tos); + if (ip_route_output_key(&rt, &key)) goto out; if (icmpv4_xrlim_allow(rt, icmp_param->data.icmph.type, icmp_param->data.icmph.code)) { @@ -392,8 +394,8 @@ struct icmp_bxm icmp_param; struct rtable *rt = (struct rtable*)skb_in->dst; struct ipcm_cookie ipc; - u32 saddr; u8 tos; + struct rt_key key = { 0 }; if (!rt) return; @@ -470,15 +472,18 @@ } #endif - saddr = iph->daddr; + key.src = iph->daddr; if (!(rt->rt_flags & RTCF_LOCAL)) - saddr = 0; + key.src = 0; tos = icmp_pointers[type].error ? ((iph->tos & IPTOS_TOS_MASK) | IPTOS_PREC_INTERNETCONTROL) : iph->tos; - if (ip_route_output(&rt, iph->saddr, saddr, RT_TOS(tos), 0)) + key.dst = iph->saddr; + key.tos = RT_TOS(tos); + + if (ip_route_output_key(&rt, &key)) goto out; if (ip_options_echo(&icmp_param.replyopts, skb_in)) @@ -502,7 +507,9 @@ ipc.opt = &icmp_param.replyopts; if (icmp_param.replyopts.srr) { ip_rt_put(rt); - if (ip_route_output(&rt, icmp_param.replyopts.faddr, saddr, RT_TOS(tos), 0)) + key.dst = icmp_param.replyopts.faddr; + + if (ip_route_output_key(&rt, &key)) goto out; } diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/igmp.c linux-2.5.7-w1/net/ipv4/igmp.c --- linux-2.5.7.orig/net/ipv4/igmp.c Sun Mar 24 12:26:19 2002 +++ linux-2.5.7-w1/net/ipv4/igmp.c Sun Mar 24 20:57:38 2002 @@ -198,16 +198,18 @@ struct iphdr *iph; struct igmphdr *ih; struct rtable *rt; - u32 dst; + struct rt_key key = { 0 }; /* According to IGMPv2 specs, LEAVE messages are * sent to all-routers group. */ - dst = group; + key.dst = group; if (type == IGMP_HOST_LEAVE_MESSAGE) - dst = IGMP_ALL_ROUTER; + key.dst = IGMP_ALL_ROUTER; - if (ip_route_output(&rt, dst, 0, 0, dev->ifindex)) + key.oif = dev->ifindex; + + if (ip_route_output_key(&rt, &key)) return -1; if (rt->rt_src == 0) { ip_rt_put(rt); @@ -231,7 +233,7 @@ iph->tos = 0; iph->frag_off = __constant_htons(IP_DF); iph->ttl = 1; - iph->daddr = dst; + iph->daddr = key.dst; iph->saddr = rt->rt_src; iph->protocol = IPPROTO_IGMP; iph->tot_len = htons(IGMP_SIZE); @@ -614,6 +616,7 @@ struct rtable *rt; struct net_device *dev = NULL; struct in_device *idev = NULL; + struct rt_key key = { dst:imr->imr_multiaddr.s_addr }; if (imr->imr_address.s_addr) { dev = ip_dev_find(imr->imr_address.s_addr); @@ -622,7 +625,7 @@ __dev_put(dev); } - if (!dev && !ip_route_output(&rt, imr->imr_multiaddr.s_addr, 0, 0, 0)) { + if (!dev && !ip_route_output_key(&rt, &key)) { dev = rt->u.dst.dev; ip_rt_put(rt); } diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/ip_gre.c linux-2.5.7-w1/net/ipv4/ip_gre.c --- linux-2.5.7.orig/net/ipv4/ip_gre.c Thu Nov 8 13:15:19 2001 +++ linux-2.5.7-w1/net/ipv4/ip_gre.c Sun Mar 24 21:38:32 2002 @@ -411,6 +411,7 @@ int grehlen = (iph->ihl<<2) + 4; struct sk_buff *skb2; struct rtable *rt; + struct rt_key key = { 0 }; if (p[1] != __constant_htons(ETH_P_IP)) return; @@ -486,7 +487,9 @@ skb2->nh.raw = skb2->data; /* Try to guess incoming interface */ - if (ip_route_output(&rt, eiph->saddr, 0, RT_TOS(eiph->tos), 0)) { + key.dst = eiph->saddr; + key.tos = RT_TOS(eiph->tos); + if (ip_route_output_key(&rt, &key)) { kfree_skb(skb2); return; } @@ -496,7 +499,9 @@ if (rt->rt_flags&RTCF_LOCAL) { ip_rt_put(rt); rt = NULL; - if (ip_route_output(&rt, eiph->daddr, eiph->saddr, eiph->tos, 0) || + key.dst = eiph->daddr; + key.src = eiph->saddr; + if (ip_route_output_key(&rt, &key) || rt->u.dst.dev->type != ARPHRD_IPGRE) { ip_rt_put(rt); kfree_skb(skb2); @@ -686,7 +691,8 @@ int gre_hlen; u32 dst; int mtu; - + struct rt_key key = { 0 }; + if (tunnel->recursion++) { tunnel->stat.collisions++; goto tx_error; @@ -747,7 +753,11 @@ tos &= ~1; } - if (ip_route_output(&rt, dst, tiph->saddr, RT_TOS(tos), tunnel->parms.link)) { + key.dst = dst; + key.src = tiph->saddr; + key.tos = tos; + key.oif = tunnel->parms.link; + if (ip_route_output_key(&rt, &key)) { tunnel->stat.tx_carrier_errors++; goto tx_error; } @@ -1100,9 +1110,9 @@ MOD_INC_USE_COUNT; if (MULTICAST(t->parms.iph.daddr)) { struct rtable *rt; - if (ip_route_output(&rt, t->parms.iph.daddr, - t->parms.iph.saddr, RT_TOS(t->parms.iph.tos), - t->parms.link)) { + struct rt_key key = { dst:t->parms.iph.daddr, src:t->parms.iph.saddr, + tos:RT_TOS(t->parms.iph.tos), oif:t->parms.link }; + if (ip_route_output_key(&rt, &key)) { MOD_DEC_USE_COUNT; return -EADDRNOTAVAIL; } @@ -1173,7 +1183,9 @@ if (iph->daddr) { struct rtable *rt; - if (!ip_route_output(&rt, iph->daddr, iph->saddr, RT_TOS(iph->tos), tunnel->parms.link)) { + struct rt_key key = { dst:iph->daddr, src:iph->saddr, + tos:RT_TOS(iph->tos), oif:tunnel->parms.link }; + if (!ip_route_output_key(&rt, &key)) { tdev = rt->u.dst.dev; ip_rt_put(rt); } diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/ip_output.c linux-2.5.7-w1/net/ipv4/ip_output.c --- linux-2.5.7.orig/net/ipv4/ip_output.c Sun Mar 24 12:30:00 2002 +++ linux-2.5.7-w1/net/ipv4/ip_output.c Sun Mar 24 21:44:42 2002 @@ -354,20 +354,21 @@ /* Make sure we can route this packet. */ rt = (struct rtable *)__sk_dst_check(sk, 0); if (rt == NULL) { - u32 daddr; + struct rt_key key = { 0 }; /* Use correct destination address if we have options. */ - daddr = inet->daddr; + key.dst = inet->daddr; if(opt && opt->srr) - daddr = opt->faddr; + key.dst = opt->faddr; /* If this fails, retransmit mechanism of transport layer will * keep trying until route appears or the connection times itself * out. */ - if (ip_route_output(&rt, daddr, inet->saddr, - RT_CONN_FLAGS(sk), - sk->bound_dev_if)) + key.src = inet->saddr; + key.tos = RT_CONN_FLAGS(sk); + key.oif = sk->bound_dev_if; + if (ip_route_output_key(&rt, &key)) goto no_route; __sk_dst_set(sk, &rt->u.dst); sk->route_caps = rt->u.dst.dev->features; @@ -956,6 +957,7 @@ struct ipcm_cookie ipc; u32 daddr; struct rtable *rt = (struct rtable*)skb->dst; + struct rt_key key = { 0 }; if (ip_options_echo(&replyopts.opt, skb)) return; @@ -970,7 +972,11 @@ daddr = replyopts.opt.faddr; } - if (ip_route_output(&rt, daddr, rt->rt_spec_dst, RT_TOS(skb->nh.iph->tos), 0)) + key.dst = daddr; + key.src = rt->rt_spec_dst; + key.tos = RT_TOS(skb->nh.iph->tos); + + if (ip_route_output_key(&rt, &key)) return; /* And let IP do all the hard work. diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/ipip.c linux-2.5.7-w1/net/ipv4/ipip.c --- linux-2.5.7.orig/net/ipv4/ipip.c Fri Oct 26 15:09:38 2001 +++ linux-2.5.7-w1/net/ipv4/ipip.c Sun Mar 24 21:52:14 2002 @@ -356,6 +356,7 @@ int rel_info = 0; struct sk_buff *skb2; struct rtable *rt; + struct rt_key key = { 0 }; if (len < hlen + sizeof(struct iphdr)) return; @@ -417,7 +418,9 @@ skb2->nh.raw = skb2->data; /* Try to guess incoming interface */ - if (ip_route_output(&rt, eiph->saddr, 0, RT_TOS(eiph->tos), 0)) { + key.dst = eiph->saddr; + key.tos = RT_TOS(eiph->tos); + if (ip_route_output_key(&rt, &key)) { kfree_skb(skb2); return; } @@ -427,7 +430,9 @@ if (rt->rt_flags&RTCF_LOCAL) { ip_rt_put(rt); rt = NULL; - if (ip_route_output(&rt, eiph->daddr, eiph->saddr, eiph->tos, 0) || + key.dst = eiph->daddr; + key.src = eiph->saddr; + if (ip_route_output_key(&rt, &key) || rt->u.dst.dev->type != ARPHRD_IPGRE) { ip_rt_put(rt); kfree_skb(skb2); @@ -538,6 +543,7 @@ int max_headroom; /* The extra header space needed */ u32 dst = tiph->daddr; int mtu; + struct rt_key key = { 0 }; if (tunnel->recursion++) { tunnel->stat.collisions++; @@ -560,7 +566,11 @@ goto tx_error_icmp; } - if (ip_route_output(&rt, dst, tiph->saddr, RT_TOS(tos), tunnel->parms.link)) { + key.dst = dst; + key.src = tiph->saddr; + key.tos = RT_TOS(tos); + key.oif = tunnel->parms.link; + if (ip_route_output_key(&rt, &key)) { tunnel->stat.tx_carrier_errors++; goto tx_error_icmp; } @@ -819,7 +829,9 @@ if (iph->daddr) { struct rtable *rt; - if (!ip_route_output(&rt, iph->daddr, iph->saddr, RT_TOS(iph->tos), tunnel->parms.link)) { + struct rt_key key = { dst:iph->daddr, src:iph->saddr, + tos:RT_TOS(iph->tos), oif:tunnel->parms.link }; + if (!ip_route_output_key(&rt, &key)) { tdev = rt->u.dst.dev; ip_rt_put(rt); } diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/ipmr.c linux-2.5.7-w1/net/ipv4/ipmr.c --- linux-2.5.7.orig/net/ipv4/ipmr.c Sun Mar 24 12:30:00 2002 +++ linux-2.5.7-w1/net/ipv4/ipmr.c Sun Mar 24 15:12:15 2002 @@ -1141,11 +1141,14 @@ #endif if (vif->flags&VIFF_TUNNEL) { - if (ip_route_output(&rt, vif->remote, vif->local, RT_TOS(iph->tos), vif->link)) + struct rt_key key = { dst:vif->remote, src:vif->local, + tos:RT_TOS(iph->tos), oif:vif->link }; + if (ip_route_output_key(&rt, &key)) return; encap = sizeof(struct iphdr); } else { - if (ip_route_output(&rt, iph->daddr, 0, RT_TOS(iph->tos), vif->link)) + struct rt_key key = { dst:iph->daddr, tos:RT_TOS(iph->tos), oif:vif->link }; + if (ip_route_output_key(&rt, &key)) return; } diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/netfilter/ip_fw_compat_masq.c linux-2.5.7-w1/net/ipv4/netfilter/ip_fw_compat_masq.c --- linux-2.5.7.orig/net/ipv4/netfilter/ip_fw_compat_masq.c Sun Mar 24 12:24:49 2002 +++ linux-2.5.7-w1/net/ipv4/netfilter/ip_fw_compat_masq.c Sun Mar 24 20:35:01 2002 @@ -70,10 +70,11 @@ u_int32_t newsrc; struct rtable *rt; struct ip_nat_multi_range range; + struct rt_key key = { dst:iph->daddr }; /* Pass 0 instead of saddr, since it's going to be changed anyway. */ - if (ip_route_output(&rt, iph->daddr, 0, 0, 0) != 0) { + if (ip_route_output_key(&rt, &key) != 0) { DEBUGP("ipnat_rule_masquerade: Can't reroute.\n"); return NF_DROP; } diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/netfilter/ip_nat_core.c linux-2.5.7-w1/net/ipv4/netfilter/ip_nat_core.c --- linux-2.5.7.orig/net/ipv4/netfilter/ip_nat_core.c Sun Mar 24 12:30:00 2002 +++ linux-2.5.7-w1/net/ipv4/netfilter/ip_nat_core.c Sun Mar 24 20:34:53 2002 @@ -204,9 +204,10 @@ do_extra_mangle(u_int32_t var_ip, u_int32_t *other_ipp) { struct rtable *rt; + struct rt_key key = { dst:var_ip }; /* FIXME: IPTOS_TOS(iph->tos) --RR */ - if (ip_route_output(&rt, var_ip, 0, 0, 0) != 0) { + if (ip_route_output_key(&rt, &key) != 0) { DEBUGP("do_extra_mangle: Can't get route to %u.%u.%u.%u\n", NIPQUAD(var_ip)); return 0; diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/netfilter/ipt_MIRROR.c linux-2.5.7-w1/net/ipv4/netfilter/ipt_MIRROR.c --- linux-2.5.7.orig/net/ipv4/netfilter/ipt_MIRROR.c Wed Jan 16 01:24:52 2002 +++ linux-2.5.7-w1/net/ipv4/netfilter/ipt_MIRROR.c Sun Mar 24 20:37:05 2002 @@ -45,13 +45,12 @@ { struct iphdr *iph = skb->nh.iph; struct rtable *rt; + struct rt_key key = { dst:iph->saddr, src:iph->daddr, + tos:RT_TOS(iph->tos) | RTO_CONN }; /* Backwards */ - if (ip_route_output(&rt, iph->saddr, iph->daddr, - RT_TOS(iph->tos) | RTO_CONN, - 0)) { + if (ip_route_output_key(&rt, &key)) return 0; - } /* check if the interface we are leaving by is the same as the one we arrived on */ diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/netfilter/ipt_REJECT.c linux-2.5.7-w1/net/ipv4/netfilter/ipt_REJECT.c --- linux-2.5.7.orig/net/ipv4/netfilter/ipt_REJECT.c Sun Mar 24 12:30:00 2002 +++ linux-2.5.7-w1/net/ipv4/netfilter/ipt_REJECT.c Sun Mar 24 20:40:13 2002 @@ -41,6 +41,7 @@ unsigned int otcplen; u_int16_t tmp; int needs_ack; + struct rt_key key = { 0 }; /* IP header checks: fragment, too short. */ if (oldskb->nh.iph->frag_off & htons(IP_OFFSET) @@ -127,10 +128,11 @@ nskb->nh.iph->ihl); /* Routing: if not headed for us, route won't like source */ - if (ip_route_output(&rt, nskb->nh.iph->daddr, - local ? nskb->nh.iph->saddr : 0, - RT_TOS(nskb->nh.iph->tos) | RTO_CONN, - 0) != 0) + key.dst = nskb->nh.iph->daddr; + key.src = local ? nskb->nh.iph->saddr : 0; + key.tos = RT_TOS(nskb->nh.iph->tos) | RTO_CONN; + + if (ip_route_output_key(&rt, &key) != 0) goto free_nskb; dst_release(nskb->dst); @@ -160,6 +162,7 @@ int hh_len, length; struct rtable *rt = (struct rtable*)skb_in->dst; unsigned char *data; + struct rt_key key = { 0 }; if (!rt) return; @@ -203,7 +206,11 @@ tos = (iph->tos & IPTOS_TOS_MASK) | IPTOS_PREC_INTERNETCONTROL; - if (ip_route_output(&rt, iph->saddr, saddr, RT_TOS(tos), 0)) + key.dst = iph->saddr; + key.src = saddr; + key.tos = RT_TOS(tos); + + if (ip_route_output_key(&rt, &key)) return; /* RFC says return as much as we can without exceeding 576 bytes. */ diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/raw.c linux-2.5.7-w1/net/ipv4/raw.c --- linux-2.5.7.orig/net/ipv4/raw.c Sun Mar 24 12:30:00 2002 +++ linux-2.5.7-w1/net/ipv4/raw.c Sun Mar 24 15:09:59 2002 @@ -315,6 +315,7 @@ u32 daddr; u8 tos; int err; + struct rt_key key = { 0 }; /* This check is ONLY to check for arithmetic overflow on integer(!) len. Not more! Real check will be made @@ -412,7 +413,12 @@ rfh.saddr = inet->mc_addr; } - err = ip_route_output(&rt, daddr, rfh.saddr, tos, ipc.oif); + key.dst = daddr; + key.src = rfh.saddr; + key.tos = tos; + key.oif = ipc.oif; + + err = ip_route_output_key(&rt, &key); if (err) goto done; diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/route.c linux-2.5.7-w1/net/ipv4/route.c --- linux-2.5.7.orig/net/ipv4/route.c Sun Mar 24 12:24:49 2002 +++ linux-2.5.7-w1/net/ipv4/route.c Sun Mar 24 20:48:56 2002 @@ -2151,10 +2151,10 @@ if (!err && rt->u.dst.error) err = -rt->u.dst.error; } else { - int oif = 0; + struct rt_key key = { dst:dst, src:src, tos:rtm->rtm_tos }; if (rta[RTA_OIF - 1]) - memcpy(&oif, RTA_DATA(rta[RTA_OIF - 1]), sizeof(int)); - err = ip_route_output(&rt, dst, src, rtm->rtm_tos, oif); + memcpy(&key.oif, RTA_DATA(rta[RTA_OIF - 1]), sizeof(int)); + err = ip_route_output_key(&rt, &key); } if (err) { kfree_skb(skb); diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/syncookies.c linux-2.5.7-w1/net/ipv4/syncookies.c --- linux-2.5.7.orig/net/ipv4/syncookies.c Sun Mar 24 12:26:19 2002 +++ linux-2.5.7-w1/net/ipv4/syncookies.c Sun Mar 24 20:32:55 2002 @@ -121,6 +121,7 @@ int mss; struct rtable *rt; __u8 rcv_wscale; + struct rt_key key = { 0 }; if (!sysctl_tcp_syncookies || !skb->h.th->ack) goto out; @@ -173,12 +174,11 @@ * hasn't changed since we received the original syn, but I see * no easy way to do this. */ - if (ip_route_output(&rt, - opt && - opt->srr ? opt->faddr : req->af.v4_req.rmt_addr, - req->af.v4_req.loc_addr, - RT_CONN_FLAGS(sk), - 0)) { + key.dst = opt && opt->srr ? opt->faddr : req->af.v4_req.rmt_addr; + key.src = req->af.v4_req.loc_addr; + key.tos = RT_CONN_FLAGS(sk); + + if (ip_route_output_key(&rt, &key)) { tcp_openreq_free(req); goto out; } diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/tcp_ipv4.c linux-2.5.7-w1/net/ipv4/tcp_ipv4.c --- linux-2.5.7.orig/net/ipv4/tcp_ipv4.c Sun Mar 24 12:30:00 2002 +++ linux-2.5.7-w1/net/ipv4/tcp_ipv4.c Sun Mar 24 15:20:20 2002 @@ -1167,14 +1167,12 @@ static struct dst_entry* tcp_v4_route_req(struct sock *sk, struct open_request *req) { struct rtable *rt; - struct ip_options *opt; - - opt = req->af.v4_req.opt; - if(ip_route_output(&rt, ((opt && opt->srr) ? - opt->faddr : - req->af.v4_req.rmt_addr), - req->af.v4_req.loc_addr, - RT_CONN_FLAGS(sk), sk->bound_dev_if)) { + struct ip_options *opt = req->af.v4_req.opt; + struct rt_key key = { dst:((opt && opt->srr) ? opt->faddr : req->af.v4_req.rmt_addr), + src: req->af.v4_req.loc_addr, + tos:RT_CONN_FLAGS(sk), oif:sk->bound_dev_if }; + + if(ip_route_output_key(&rt, &key)) { IP_INC_STATS_BH(IpOutNoRoutes); return NULL; } @@ -1796,20 +1794,23 @@ { struct inet_opt *inet = inet_sk(sk); struct rtable *rt = (struct rtable *)__sk_dst_check(sk, 0); - u32 daddr; int err; + struct rt_key key = { 0 }; /* Route is OK, nothing to do. */ if (rt != NULL) return 0; /* Reroute. */ - daddr = inet->daddr; + key.dst = inet->daddr; if (inet->opt && inet->opt->srr) - daddr = inet->opt->faddr; + key.dst = inet->opt->faddr; - err = ip_route_output(&rt, daddr, inet->saddr, - RT_CONN_FLAGS(sk), sk->bound_dev_if); + key.src = inet->saddr; + key.tos = RT_CONN_FLAGS(sk); + key.oif = sk->bound_dev_if; + + err = ip_route_output_key(&rt, &key); if (!err) { __sk_dst_set(sk, &rt->u.dst); sk->route_caps = rt->u.dst.dev->features; diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv4/udp.c linux-2.5.7-w1/net/ipv4/udp.c --- linux-2.5.7.orig/net/ipv4/udp.c Sun Mar 24 12:30:00 2002 +++ linux-2.5.7-w1/net/ipv4/udp.c Sun Mar 24 20:55:04 2002 @@ -528,7 +528,9 @@ rt = (struct rtable*)sk_dst_check(sk, 0); if (rt == NULL) { - err = ip_route_output(&rt, daddr, ufh.saddr, tos, ipc.oif); + struct rt_key key = { dst:daddr, src:ufh.saddr, tos:tos, oif:ipc.oif }; + + err = ip_route_output_key(&rt, &key); if (err) goto out; diff -urN -X /usr/src/misc/xkdiff linux-2.5.7.orig/net/ipv6/sit.c linux-2.5.7-w1/net/ipv6/sit.c --- linux-2.5.7.orig/net/ipv6/sit.c Thu Oct 11 19:18:00 2001 +++ linux-2.5.7-w1/net/ipv6/sit.c Sun Mar 24 20:43:31 2002 @@ -463,6 +463,7 @@ int mtu; struct in6_addr *addr6; int addr_type; + struct rt_key key = { 0 }; if (tunnel->recursion++) { tunnel->stat.collisions++; @@ -500,8 +501,13 @@ dst = addr6->s6_addr32[3]; } - - if (ip_route_output(&rt, dst, tiph->saddr, RT_TOS(tos), tunnel->parms.link)) { + + key.dst = dst; + key.src = tiph->saddr; + key.tos = RT_TOS(tos); + key.oif = tunnel->parms.link; + + if (ip_route_output_key(&rt, &key)) { tunnel->stat.tx_carrier_errors++; goto tx_error_icmp; } @@ -773,7 +779,9 @@ if (iph->daddr) { struct rtable *rt; - if (!ip_route_output(&rt, iph->daddr, iph->saddr, RT_TOS(iph->tos), tunnel->parms.link)) { + struct rt_key key = { dst:iph->daddr, src:iph->saddr, + tos:RT_TOS(iph->tos), oif:tunnel->parms.link }; + if (!ip_route_output_key(&rt, &key)) { tdev = rt->u.dst.dev; ip_rt_put(rt); } --550177381-301911034-1016975646=:24449 Content-Type: TEXT/plain; name="diff-routekey-01.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="diff-routekey-01.txt" ZGlmZiAtdXJOIC1YIC91c3Ivc3JjL21pc2MveGtkaWZmIGxpbnV4LTIuNS43 Lm9yaWcvaW5jbHVkZS9uZXQvcm91dGUuaCBsaW51eC0yLjUuNy13MS9pbmNs dWRlL25ldC9yb3V0ZS5oDQotLS0gbGludXgtMi41Ljcub3JpZy9pbmNsdWRl L25ldC9yb3V0ZS5oCVN1biBNYXIgMjQgMTI6MjY6MTkgMjAwMg0KKysrIGxp bnV4LTIuNS43LXcxL2luY2x1ZGUvbmV0L3JvdXRlLmgJU3VuIE1hciAyNCAy MTowMzoxMyAyMDAyDQpAQCAtMTMyLDE2ICsxMzIsNiBAQA0KIGV4dGVybiB2 b2lkCQlpcF9ydF9nZXRfc291cmNlKHU4ICpzcmMsIHN0cnVjdCBydGFibGUg KnJ0KTsNCiBleHRlcm4gaW50CQlpcF9ydF9kdW1wKHN0cnVjdCBza19idWZm ICpza2IsICBzdHJ1Y3QgbmV0bGlua19jYWxsYmFjayAqY2IpOw0KIA0KLS8q IERlcHJlY2F0ZWQ6IHVzZSBpcF9yb3V0ZV9vdXRwdXRfa2V5IGRpcmVjdGx5 ICovDQotc3RhdGljIGlubGluZSBpbnQgaXBfcm91dGVfb3V0cHV0KHN0cnVj dCBydGFibGUgKipycCwNCi0JCQkJICAgICAgdTMyIGRhZGRyLCB1MzIgc2Fk ZHIsIHUzMiB0b3MsIGludCBvaWYpDQotew0KLQlzdHJ1Y3QgcnRfa2V5IGtl eSA9IHsgZHN0OmRhZGRyLCBzcmM6c2FkZHIsIG9pZjpvaWYsIHRvczp0b3Mg fTsNCi0NCi0JcmV0dXJuIGlwX3JvdXRlX291dHB1dF9rZXkocnAsICZrZXkp Ow0KLX0NCi0NCi0NCiBzdGF0aWMgaW5saW5lIHZvaWQgaXBfcnRfcHV0KHN0 cnVjdCBydGFibGUgKiBydCkNCiB7DQogCWlmIChydCkNCkBAIC0xNjAsMTQg KzE1MCwxNiBAQA0KIHN0YXRpYyBpbmxpbmUgaW50IGlwX3JvdXRlX2Nvbm5l Y3Qoc3RydWN0IHJ0YWJsZSAqKnJwLCB1MzIgZHN0LCB1MzIgc3JjLCB1MzIg dG9zLCBpbnQgb2lmKQ0KIHsNCiAJaW50IGVycjsNCi0JZXJyID0gaXBfcm91 dGVfb3V0cHV0KHJwLCBkc3QsIHNyYywgdG9zLCBvaWYpOw0KKwlzdHJ1Y3Qg cnRfa2V5IGtleSA9IHsgZHN0OmRzdCwgc3JjOnNyYywgdG9zOnRvcywgb2lm Om9pZiB9Ow0KKwkNCisJZXJyID0gaXBfcm91dGVfb3V0cHV0X2tleShycCwg JmtleSk7DQogCWlmIChlcnIgfHwgKGRzdCAmJiBzcmMpKQ0KIAkJcmV0dXJu IGVycjsNCi0JZHN0ID0gKCpycCktPnJ0X2RzdDsNCi0Jc3JjID0gKCpycCkt PnJ0X3NyYzsNCisJa2V5LmRzdCA9ICgqcnApLT5ydF9kc3Q7DQorCWtleS5z cmMgPSAoKnJwKS0+cnRfc3JjOw0KIAlpcF9ydF9wdXQoKnJwKTsNCiAJKnJw ID0gTlVMTDsNCi0JcmV0dXJuIGlwX3JvdXRlX291dHB1dChycCwgZHN0LCBz cmMsIHRvcywgb2lmKTsNCisJcmV0dXJuIGlwX3JvdXRlX291dHB1dF9rZXko cnAsICZrZXkpOw0KIH0NCiANCiBleHRlcm4gdm9pZCBydF9iaW5kX3BlZXIo c3RydWN0IHJ0YWJsZSAqcnQsIGludCBjcmVhdGUpOw0KZGlmZiAtdXJOIC1Y IC91c3Ivc3JjL21pc2MveGtkaWZmIGxpbnV4LTIuNS43Lm9yaWcvbmV0L2F0 bS9jbGlwLmMgbGludXgtMi41LjctdzEvbmV0L2F0bS9jbGlwLmMNCi0tLSBs aW51eC0yLjUuNy5vcmlnL25ldC9hdG0vY2xpcC5jCVdlZCBKdWwgIDQgMjE6 Mjc6MzEgMjAwMQ0KKysrIGxpbnV4LTIuNS43LXcxL25ldC9hdG0vY2xpcC5j CVN1biBNYXIgMjQgMjA6NDU6NTQgMjAwMg0KQEAgLTUxMCw2ICs1MTAsNyBA QA0KIAlpbnQgZXJyb3I7DQogCXN0cnVjdCBjbGlwX3ZjYyAqY2xpcF92Y2M7 DQogCXN0cnVjdCBydGFibGUgKnJ0Ow0KKwlzdHJ1Y3QgcnRfa2V5IGtleSA9 IHsgZHN0OmlwLCB0b3M6MSB9Ow0KIA0KIAlpZiAodmNjLT5wdXNoICE9IGNs aXBfcHVzaCkgew0KIAkJcHJpbnRrKEtFUk5fV0FSTklORyAiY2xpcF9zZXRl bnRyeTogbm9uLUNMSVAgVkNDXG4iKTsNCkBAIC01MjUsNyArNTI2LDcgQEAN CiAJCXVubGlua19jbGlwX3ZjYyhjbGlwX3ZjYyk7DQogCQlyZXR1cm4gMDsN CiAJfQ0KLQllcnJvciA9IGlwX3JvdXRlX291dHB1dCgmcnQsaXAsMCwxLDAp Ow0KKwllcnJvciA9IGlwX3JvdXRlX291dHB1dF9rZXkoJnJ0LCZrZXkpOw0K IAlpZiAoZXJyb3IpIHJldHVybiBlcnJvcjsNCiAJbmVpZ2ggPSBfX25laWdo X2xvb2t1cCgmY2xpcF90YmwsJmlwLHJ0LT51LmRzdC5kZXYsMSk7DQogCWlw X3J0X3B1dChydCk7DQpkaWZmIC11ck4gLVggL3Vzci9zcmMvbWlzYy94a2Rp ZmYgbGludXgtMi41Ljcub3JpZy9uZXQvaXB2NC9hcnAuYyBsaW51eC0yLjUu Ny13MS9uZXQvaXB2NC9hcnAuYw0KLS0tIGxpbnV4LTIuNS43Lm9yaWcvbmV0 L2lwdjQvYXJwLmMJU3VuIE1hciAyNCAxMjozMDowMCAyMDAyDQorKysgbGlu dXgtMi41LjctdzEvbmV0L2lwdjQvYXJwLmMJU3VuIE1hciAyNCAyMDo1NToy OCAyMDAyDQpAQCAtMzUwLDggKzM1MCw5IEBADQogCXN0cnVjdCBydGFibGUg KnJ0Ow0KIAlpbnQgZmxhZyA9IDA7IA0KIAkvKnVuc2lnbmVkIGxvbmcgbm93 OyAqLw0KKwlzdHJ1Y3QgcnRfa2V5IGtleSA9IHsgZHN0OnNpcCwgc3JjOnRp cCB9Ow0KIA0KLQlpZiAoaXBfcm91dGVfb3V0cHV0KCZydCwgc2lwLCB0aXAs IDAsIDApIDwgMCkgDQorCWlmIChpcF9yb3V0ZV9vdXRwdXRfa2V5KCZydCwg JmtleSkpDQogCQlyZXR1cm4gMTsNCiAJaWYgKHJ0LT51LmRzdC5kZXYgIT0g ZGV2KSB7IA0KIAkJTkVUX0lOQ19TVEFUU19CSChBcnBGaWx0ZXIpOw0KQEAg LTg5Myw3ICs4OTQsOCBAQA0KIAkJci0+YXJwX2ZsYWdzIHw9IEFURl9DT007 DQogCWlmIChkZXYgPT0gTlVMTCkgew0KIAkJc3RydWN0IHJ0YWJsZSAqIHJ0 Ow0KLQkJaWYgKChlcnIgPSBpcF9yb3V0ZV9vdXRwdXQoJnJ0LCBpcCwgMCwg UlRPX09OTElOSywgMCkpICE9IDApDQorCQlzdHJ1Y3QgcnRfa2V5IGtleSA9 IHsgZHN0OmlwLCB0b3M6UlRPX09OTElOSyB9Ow0KKwkJaWYgKChlcnIgPSBp cF9yb3V0ZV9vdXRwdXRfa2V5KCZydCwgJmtleSkpICE9IDApDQogCQkJcmV0 dXJuIGVycjsNCiAJCWRldiA9IHJ0LT51LmRzdC5kZXY7DQogCQlpcF9ydF9w dXQocnQpOw0KQEAgLTk3Niw3ICs5NzgsOCBAQA0KIA0KIAlpZiAoZGV2ID09 IE5VTEwpIHsNCiAJCXN0cnVjdCBydGFibGUgKiBydDsNCi0JCWlmICgoZXJy ID0gaXBfcm91dGVfb3V0cHV0KCZydCwgaXAsIDAsIFJUT19PTkxJTkssIDAp KSAhPSAwKQ0KKwkJc3RydWN0IHJ0X2tleSBrZXkgPSB7IGRzdDppcCwgdG9z OlJUT19PTkxJTksgfTsNCisJCWlmICgoZXJyID0gaXBfcm91dGVfb3V0cHV0 X2tleSgmcnQsICZrZXkpKSAhPSAwKQ0KIAkJCXJldHVybiBlcnI7DQogCQlk ZXYgPSBydC0+dS5kc3QuZGV2Ow0KIAkJaXBfcnRfcHV0KHJ0KTsNCmRpZmYg LXVyTiAtWCAvdXNyL3NyYy9taXNjL3hrZGlmZiBsaW51eC0yLjUuNy5vcmln L25ldC9pcHY0L2ljbXAuYyBsaW51eC0yLjUuNy13MS9uZXQvaXB2NC9pY21w LmMNCi0tLSBsaW51eC0yLjUuNy5vcmlnL25ldC9pcHY0L2ljbXAuYwlTdW4g TWFyIDI0IDEyOjI2OjE5IDIwMDINCisrKyBsaW51eC0yLjUuNy13MS9uZXQv aXB2NC9pY21wLmMJU3VuIE1hciAyNCAyMDo1NjozNSAyMDAyDQpAQCAtMzQx LDcgKzM0MSw3IEBADQogCXN0cnVjdCBpbmV0X29wdCAqaW5ldCA9IGluZXRf c2soc2spOw0KIAlzdHJ1Y3QgaXBjbV9jb29raWUgaXBjOw0KIAlzdHJ1Y3Qg cnRhYmxlICpydCA9IChzdHJ1Y3QgcnRhYmxlKilza2ItPmRzdDsNCi0JdTMy IGRhZGRyOw0KKwlzdHJ1Y3QgcnRfa2V5IGtleSA9IHsgMCB9Ow0KIA0KIAlp ZiAoaXBfb3B0aW9uc19lY2hvKCZpY21wX3BhcmFtLT5yZXBseW9wdHMsIHNr YikpDQogCQlyZXR1cm47DQpAQCAtMzU0LDE0ICszNTQsMTYgQEANCiAJaWNt cF9vdXRfY291bnQoaWNtcF9wYXJhbS0+ZGF0YS5pY21waC50eXBlKTsNCiAN CiAJaW5ldC0+dG9zID0gc2tiLT5uaC5pcGgtPnRvczsNCi0JZGFkZHIgPSBp cGMuYWRkciA9IHJ0LT5ydF9zcmM7DQorCWtleS5kc3QgPSBpcGMuYWRkciA9 IHJ0LT5ydF9zcmM7DQogCWlwYy5vcHQgPSBOVUxMOw0KIAlpZiAoaWNtcF9w YXJhbS0+cmVwbHlvcHRzLm9wdGxlbikgew0KIAkJaXBjLm9wdCA9ICZpY21w X3BhcmFtLT5yZXBseW9wdHM7DQogCQlpZiAoaXBjLm9wdC0+c3JyKQ0KLQkJ CWRhZGRyID0gaWNtcF9wYXJhbS0+cmVwbHlvcHRzLmZhZGRyOw0KKwkJCWtl eS5kc3QgPSBpY21wX3BhcmFtLT5yZXBseW9wdHMuZmFkZHI7DQogCX0NCi0J aWYgKGlwX3JvdXRlX291dHB1dCgmcnQsIGRhZGRyLCBydC0+cnRfc3BlY19k c3QsIFJUX1RPUyhza2ItPm5oLmlwaC0+dG9zKSwgMCkpDQorCWtleS5zcmMg PSBydC0+cnRfc3BlY19kc3Q7DQorCWtleS50b3MgPSBSVF9UT1Moc2tiLT5u aC5pcGgtPnRvcyk7DQorCWlmIChpcF9yb3V0ZV9vdXRwdXRfa2V5KCZydCwg JmtleSkpDQogCQlnb3RvIG91dDsNCiAJaWYgKGljbXB2NF94cmxpbV9hbGxv dyhydCwgaWNtcF9wYXJhbS0+ZGF0YS5pY21waC50eXBlLCANCiAJCQkgICAg ICAgaWNtcF9wYXJhbS0+ZGF0YS5pY21waC5jb2RlKSkgeyANCkBAIC0zOTIs OCArMzk0LDggQEANCiAJc3RydWN0IGljbXBfYnhtIGljbXBfcGFyYW07DQog CXN0cnVjdCBydGFibGUgKnJ0ID0gKHN0cnVjdCBydGFibGUqKXNrYl9pbi0+ ZHN0Ow0KIAlzdHJ1Y3QgaXBjbV9jb29raWUgaXBjOw0KLQl1MzIgc2FkZHI7 DQogCXU4ICB0b3M7DQorCXN0cnVjdCBydF9rZXkga2V5ID0geyAwIH07DQog DQogCWlmICghcnQpDQogCQlyZXR1cm47DQpAQCAtNDcwLDE1ICs0NzIsMTgg QEANCiAJfQ0KICNlbmRpZg0KIA0KLQlzYWRkciA9IGlwaC0+ZGFkZHI7DQor CWtleS5zcmMgPSBpcGgtPmRhZGRyOw0KIAlpZiAoIShydC0+cnRfZmxhZ3Mg JiBSVENGX0xPQ0FMKSkNCi0JCXNhZGRyID0gMDsNCisJCWtleS5zcmMgPSAw Ow0KIA0KIAl0b3MgPSBpY21wX3BvaW50ZXJzW3R5cGVdLmVycm9yID8NCiAJ CSgoaXBoLT50b3MgJiBJUFRPU19UT1NfTUFTSykgfCBJUFRPU19QUkVDX0lO VEVSTkVUQ09OVFJPTCkgOg0KIAkJCWlwaC0+dG9zOw0KIA0KLQlpZiAoaXBf cm91dGVfb3V0cHV0KCZydCwgaXBoLT5zYWRkciwgc2FkZHIsIFJUX1RPUyh0 b3MpLCAwKSkNCisJa2V5LmRzdCA9IGlwaC0+c2FkZHI7DQorCWtleS50b3Mg PSBSVF9UT1ModG9zKTsNCisJDQorCWlmIChpcF9yb3V0ZV9vdXRwdXRfa2V5 KCZydCwgJmtleSkpDQogCQlnb3RvIG91dDsNCiANCiAJaWYgKGlwX29wdGlv bnNfZWNobygmaWNtcF9wYXJhbS5yZXBseW9wdHMsIHNrYl9pbikpIA0KQEAg LTUwMiw3ICs1MDcsOSBAQA0KIAlpcGMub3B0ID0gJmljbXBfcGFyYW0ucmVw bHlvcHRzOw0KIAlpZiAoaWNtcF9wYXJhbS5yZXBseW9wdHMuc3JyKSB7DQog CQlpcF9ydF9wdXQocnQpOw0KLQkJaWYgKGlwX3JvdXRlX291dHB1dCgmcnQs IGljbXBfcGFyYW0ucmVwbHlvcHRzLmZhZGRyLCBzYWRkciwgUlRfVE9TKHRv cyksIDApKQ0KKwkJa2V5LmRzdCA9IGljbXBfcGFyYW0ucmVwbHlvcHRzLmZh ZGRyOw0KKwkJDQorCQlpZiAoaXBfcm91dGVfb3V0cHV0X2tleSgmcnQsICZr ZXkpKQ0KIAkJCWdvdG8gb3V0Ow0KIAl9DQogDQpkaWZmIC11ck4gLVggL3Vz ci9zcmMvbWlzYy94a2RpZmYgbGludXgtMi41Ljcub3JpZy9uZXQvaXB2NC9p Z21wLmMgbGludXgtMi41LjctdzEvbmV0L2lwdjQvaWdtcC5jDQotLS0gbGlu dXgtMi41Ljcub3JpZy9uZXQvaXB2NC9pZ21wLmMJU3VuIE1hciAyNCAxMjoy NjoxOSAyMDAyDQorKysgbGludXgtMi41LjctdzEvbmV0L2lwdjQvaWdtcC5j CVN1biBNYXIgMjQgMjA6NTc6MzggMjAwMg0KQEAgLTE5OCwxNiArMTk4LDE4 IEBADQogCXN0cnVjdCBpcGhkciAqaXBoOw0KIAlzdHJ1Y3QgaWdtcGhkciAq aWg7DQogCXN0cnVjdCBydGFibGUgKnJ0Ow0KLQl1MzIJZHN0Ow0KKwlzdHJ1 Y3QgcnRfa2V5IGtleSA9IHsgMCB9Ow0KIA0KIAkvKiBBY2NvcmRpbmcgdG8g SUdNUHYyIHNwZWNzLCBMRUFWRSBtZXNzYWdlcyBhcmUNCiAJICogc2VudCB0 byBhbGwtcm91dGVycyBncm91cC4NCiAJICovDQotCWRzdCA9IGdyb3VwOw0K KwlrZXkuZHN0ID0gZ3JvdXA7DQogCWlmICh0eXBlID09IElHTVBfSE9TVF9M RUFWRV9NRVNTQUdFKQ0KLQkJZHN0ID0gSUdNUF9BTExfUk9VVEVSOw0KKwkJ a2V5LmRzdCA9IElHTVBfQUxMX1JPVVRFUjsNCiANCi0JaWYgKGlwX3JvdXRl X291dHB1dCgmcnQsIGRzdCwgMCwgMCwgZGV2LT5pZmluZGV4KSkNCisJa2V5 Lm9pZiA9IGRldi0+aWZpbmRleDsNCisJDQorCWlmIChpcF9yb3V0ZV9vdXRw dXRfa2V5KCZydCwgJmtleSkpDQogCQlyZXR1cm4gLTE7DQogCWlmIChydC0+ cnRfc3JjID09IDApIHsNCiAJCWlwX3J0X3B1dChydCk7DQpAQCAtMjMxLDcg KzIzMyw3IEBADQogCWlwaC0+dG9zICAgICAgPSAwOw0KIAlpcGgtPmZyYWdf b2ZmID0gX19jb25zdGFudF9odG9ucyhJUF9ERik7DQogCWlwaC0+dHRsICAg ICAgPSAxOw0KLQlpcGgtPmRhZGRyICAgID0gZHN0Ow0KKwlpcGgtPmRhZGRy ICAgID0ga2V5LmRzdDsNCiAJaXBoLT5zYWRkciAgICA9IHJ0LT5ydF9zcmM7 DQogCWlwaC0+cHJvdG9jb2wgPSBJUFBST1RPX0lHTVA7DQogCWlwaC0+dG90 X2xlbiAgPSBodG9ucyhJR01QX1NJWkUpOw0KQEAgLTYxNCw2ICs2MTYsNyBA QA0KIAlzdHJ1Y3QgcnRhYmxlICpydDsNCiAJc3RydWN0IG5ldF9kZXZpY2Ug KmRldiA9IE5VTEw7DQogCXN0cnVjdCBpbl9kZXZpY2UgKmlkZXYgPSBOVUxM Ow0KKwlzdHJ1Y3QgcnRfa2V5IGtleSA9IHsgZHN0Omltci0+aW1yX211bHRp YWRkci5zX2FkZHIgfTsNCiANCiAJaWYgKGltci0+aW1yX2FkZHJlc3Muc19h ZGRyKSB7DQogCQlkZXYgPSBpcF9kZXZfZmluZChpbXItPmltcl9hZGRyZXNz LnNfYWRkcik7DQpAQCAtNjIyLDcgKzYyNSw3IEBADQogCQlfX2Rldl9wdXQo ZGV2KTsNCiAJfQ0KIA0KLQlpZiAoIWRldiAmJiAhaXBfcm91dGVfb3V0cHV0 KCZydCwgaW1yLT5pbXJfbXVsdGlhZGRyLnNfYWRkciwgMCwgMCwgMCkpIHsN CisJaWYgKCFkZXYgJiYgIWlwX3JvdXRlX291dHB1dF9rZXkoJnJ0LCAma2V5 KSkgew0KIAkJZGV2ID0gcnQtPnUuZHN0LmRldjsNCiAJCWlwX3J0X3B1dChy dCk7DQogCX0NCmRpZmYgLXVyTiAtWCAvdXNyL3NyYy9taXNjL3hrZGlmZiBs aW51eC0yLjUuNy5vcmlnL25ldC9pcHY0L2lwX2dyZS5jIGxpbnV4LTIuNS43 LXcxL25ldC9pcHY0L2lwX2dyZS5jDQotLS0gbGludXgtMi41Ljcub3JpZy9u ZXQvaXB2NC9pcF9ncmUuYwlUaHUgTm92ICA4IDEzOjE1OjE5IDIwMDENCisr KyBsaW51eC0yLjUuNy13MS9uZXQvaXB2NC9pcF9ncmUuYwlTdW4gTWFyIDI0 IDIxOjM4OjMyIDIwMDINCkBAIC00MTEsNiArNDExLDcgQEANCiAJaW50IGdy ZWhsZW4gPSAoaXBoLT5paGw8PDIpICsgNDsNCiAJc3RydWN0IHNrX2J1ZmYg KnNrYjI7DQogCXN0cnVjdCBydGFibGUgKnJ0Ow0KKwlzdHJ1Y3QgcnRfa2V5 IGtleSA9IHsgMCB9Ow0KIA0KIAlpZiAocFsxXSAhPSBfX2NvbnN0YW50X2h0 b25zKEVUSF9QX0lQKSkNCiAJCXJldHVybjsNCkBAIC00ODYsNyArNDg3LDkg QEANCiAJc2tiMi0+bmgucmF3ID0gc2tiMi0+ZGF0YTsNCiANCiAJLyogVHJ5 IHRvIGd1ZXNzIGluY29taW5nIGludGVyZmFjZSAqLw0KLQlpZiAoaXBfcm91 dGVfb3V0cHV0KCZydCwgZWlwaC0+c2FkZHIsIDAsIFJUX1RPUyhlaXBoLT50 b3MpLCAwKSkgew0KKwlrZXkuZHN0ID0gZWlwaC0+c2FkZHI7DQorCWtleS50 b3MgPSBSVF9UT1MoZWlwaC0+dG9zKTsNCisJaWYgKGlwX3JvdXRlX291dHB1 dF9rZXkoJnJ0LCAma2V5KSkgew0KIAkJa2ZyZWVfc2tiKHNrYjIpOw0KIAkJ cmV0dXJuOw0KIAl9DQpAQCAtNDk2LDcgKzQ5OSw5IEBADQogCWlmIChydC0+ cnRfZmxhZ3MmUlRDRl9MT0NBTCkgew0KIAkJaXBfcnRfcHV0KHJ0KTsNCiAJ CXJ0ID0gTlVMTDsNCi0JCWlmIChpcF9yb3V0ZV9vdXRwdXQoJnJ0LCBlaXBo LT5kYWRkciwgZWlwaC0+c2FkZHIsIGVpcGgtPnRvcywgMCkgfHwNCisJCWtl eS5kc3QgPSBlaXBoLT5kYWRkcjsNCisJCWtleS5zcmMgPSBlaXBoLT5zYWRk cjsNCisJCWlmIChpcF9yb3V0ZV9vdXRwdXRfa2V5KCZydCwgJmtleSkgfHwN CiAJCSAgICBydC0+dS5kc3QuZGV2LT50eXBlICE9IEFSUEhSRF9JUEdSRSkg ew0KIAkJCWlwX3J0X3B1dChydCk7DQogCQkJa2ZyZWVfc2tiKHNrYjIpOw0K QEAgLTY4Niw3ICs2OTEsOCBAQA0KIAlpbnQgICAgZ3JlX2hsZW47DQogCXUz MiAgICBkc3Q7DQogCWludCAgICBtdHU7DQotDQorCXN0cnVjdCBydF9rZXkg a2V5ID0geyAwIH07DQorCQ0KIAlpZiAodHVubmVsLT5yZWN1cnNpb24rKykg ew0KIAkJdHVubmVsLT5zdGF0LmNvbGxpc2lvbnMrKzsNCiAJCWdvdG8gdHhf ZXJyb3I7DQpAQCAtNzQ3LDcgKzc1MywxMSBAQA0KIAkJdG9zICY9IH4xOw0K IAl9DQogDQotCWlmIChpcF9yb3V0ZV9vdXRwdXQoJnJ0LCBkc3QsIHRpcGgt PnNhZGRyLCBSVF9UT1ModG9zKSwgdHVubmVsLT5wYXJtcy5saW5rKSkgew0K KwlrZXkuZHN0ID0gZHN0Ow0KKwlrZXkuc3JjID0gdGlwaC0+c2FkZHI7DQor CWtleS50b3MgPSB0b3M7DQorCWtleS5vaWYgPSB0dW5uZWwtPnBhcm1zLmxp bms7DQorCWlmIChpcF9yb3V0ZV9vdXRwdXRfa2V5KCZydCwgJmtleSkpIHsN CiAJCXR1bm5lbC0+c3RhdC50eF9jYXJyaWVyX2Vycm9ycysrOw0KIAkJZ290 byB0eF9lcnJvcjsNCiAJfQ0KQEAgLTExMDAsOSArMTExMCw5IEBADQogCU1P RF9JTkNfVVNFX0NPVU5UOw0KIAlpZiAoTVVMVElDQVNUKHQtPnBhcm1zLmlw aC5kYWRkcikpIHsNCiAJCXN0cnVjdCBydGFibGUgKnJ0Ow0KLQkJaWYgKGlw X3JvdXRlX291dHB1dCgmcnQsIHQtPnBhcm1zLmlwaC5kYWRkciwNCi0JCQkJ ICAgIHQtPnBhcm1zLmlwaC5zYWRkciwgUlRfVE9TKHQtPnBhcm1zLmlwaC50 b3MpLCANCi0JCQkJICAgIHQtPnBhcm1zLmxpbmspKSB7DQorCQlzdHJ1Y3Qg cnRfa2V5IGtleSA9IHsgZHN0OnQtPnBhcm1zLmlwaC5kYWRkciwgc3JjOnQt PnBhcm1zLmlwaC5zYWRkciwNCisJCSAgICAgICAgICAgICAgICAgICAgICB0 b3M6UlRfVE9TKHQtPnBhcm1zLmlwaC50b3MpLCBvaWY6dC0+cGFybXMubGlu ayB9Ow0KKwkJaWYgKGlwX3JvdXRlX291dHB1dF9rZXkoJnJ0LCAma2V5KSkg ew0KIAkJCU1PRF9ERUNfVVNFX0NPVU5UOw0KIAkJCXJldHVybiAtRUFERFJO T1RBVkFJTDsNCiAJCX0NCkBAIC0xMTczLDcgKzExODMsOSBAQA0KIA0KIAlp ZiAoaXBoLT5kYWRkcikgew0KIAkJc3RydWN0IHJ0YWJsZSAqcnQ7DQotCQlp ZiAoIWlwX3JvdXRlX291dHB1dCgmcnQsIGlwaC0+ZGFkZHIsIGlwaC0+c2Fk ZHIsIFJUX1RPUyhpcGgtPnRvcyksIHR1bm5lbC0+cGFybXMubGluaykpIHsN CisJCXN0cnVjdCBydF9rZXkga2V5ID0geyBkc3Q6aXBoLT5kYWRkciwgc3Jj OmlwaC0+c2FkZHIsDQorCQkgICAgICAgICAgICAgICAgICAgICAgdG9zOlJU X1RPUyhpcGgtPnRvcyksIG9pZjp0dW5uZWwtPnBhcm1zLmxpbmsgfTsNCisJ CWlmICghaXBfcm91dGVfb3V0cHV0X2tleSgmcnQsICZrZXkpKSB7DQogCQkJ dGRldiA9IHJ0LT51LmRzdC5kZXY7DQogCQkJaXBfcnRfcHV0KHJ0KTsNCiAJ CX0NCmRpZmYgLXVyTiAtWCAvdXNyL3NyYy9taXNjL3hrZGlmZiBsaW51eC0y LjUuNy5vcmlnL25ldC9pcHY0L2lwX291dHB1dC5jIGxpbnV4LTIuNS43LXcx L25ldC9pcHY0L2lwX291dHB1dC5jDQotLS0gbGludXgtMi41Ljcub3JpZy9u ZXQvaXB2NC9pcF9vdXRwdXQuYwlTdW4gTWFyIDI0IDEyOjMwOjAwIDIwMDIN CisrKyBsaW51eC0yLjUuNy13MS9uZXQvaXB2NC9pcF9vdXRwdXQuYwlTdW4g TWFyIDI0IDIxOjQ0OjQyIDIwMDINCkBAIC0zNTQsMjAgKzM1NCwyMSBAQA0K IAkvKiBNYWtlIHN1cmUgd2UgY2FuIHJvdXRlIHRoaXMgcGFja2V0LiAqLw0K IAlydCA9IChzdHJ1Y3QgcnRhYmxlICopX19za19kc3RfY2hlY2soc2ssIDAp Ow0KIAlpZiAocnQgPT0gTlVMTCkgew0KLQkJdTMyIGRhZGRyOw0KKwkJc3Ry dWN0IHJ0X2tleSBrZXkgPSB7IDAgfTsNCiANCiAJCS8qIFVzZSBjb3JyZWN0 IGRlc3RpbmF0aW9uIGFkZHJlc3MgaWYgd2UgaGF2ZSBvcHRpb25zLiAqLw0K LQkJZGFkZHIgPSBpbmV0LT5kYWRkcjsNCisJCWtleS5kc3QgPSBpbmV0LT5k YWRkcjsNCiAJCWlmKG9wdCAmJiBvcHQtPnNycikNCi0JCQlkYWRkciA9IG9w dC0+ZmFkZHI7DQorCQkJa2V5LmRzdCA9IG9wdC0+ZmFkZHI7DQogDQogCQkv KiBJZiB0aGlzIGZhaWxzLCByZXRyYW5zbWl0IG1lY2hhbmlzbSBvZiB0cmFu c3BvcnQgbGF5ZXIgd2lsbA0KIAkJICoga2VlcCB0cnlpbmcgdW50aWwgcm91 dGUgYXBwZWFycyBvciB0aGUgY29ubmVjdGlvbiB0aW1lcyBpdHNlbGYNCiAJ CSAqIG91dC4NCiAJCSAqLw0KLQkJaWYgKGlwX3JvdXRlX291dHB1dCgmcnQs IGRhZGRyLCBpbmV0LT5zYWRkciwNCi0JCQkJICAgIFJUX0NPTk5fRkxBR1Mo c2spLA0KLQkJCQkgICAgc2stPmJvdW5kX2Rldl9pZikpDQorCQlrZXkuc3Jj ID0gaW5ldC0+c2FkZHI7DQorCQlrZXkudG9zID0gUlRfQ09OTl9GTEFHUyhz ayk7DQorCQlrZXkub2lmID0gc2stPmJvdW5kX2Rldl9pZjsgDQorCQlpZiAo aXBfcm91dGVfb3V0cHV0X2tleSgmcnQsICZrZXkpKQ0KIAkJCWdvdG8gbm9f cm91dGU7DQogCQlfX3NrX2RzdF9zZXQoc2ssICZydC0+dS5kc3QpOw0KIAkJ c2stPnJvdXRlX2NhcHMgPSBydC0+dS5kc3QuZGV2LT5mZWF0dXJlczsNCkBA IC05NTYsNiArOTU3LDcgQEANCiAJc3RydWN0IGlwY21fY29va2llIGlwYzsN CiAJdTMyIGRhZGRyOw0KIAlzdHJ1Y3QgcnRhYmxlICpydCA9IChzdHJ1Y3Qg cnRhYmxlKilza2ItPmRzdDsNCisJc3RydWN0IHJ0X2tleSBrZXkgPSB7IDAg fTsNCiANCiAJaWYgKGlwX29wdGlvbnNfZWNobygmcmVwbHlvcHRzLm9wdCwg c2tiKSkNCiAJCXJldHVybjsNCkBAIC05NzAsNyArOTcyLDExIEBADQogCQkJ ZGFkZHIgPSByZXBseW9wdHMub3B0LmZhZGRyOw0KIAl9DQogDQotCWlmIChp cF9yb3V0ZV9vdXRwdXQoJnJ0LCBkYWRkciwgcnQtPnJ0X3NwZWNfZHN0LCBS VF9UT1Moc2tiLT5uaC5pcGgtPnRvcyksIDApKQ0KKwlrZXkuZHN0ID0gZGFk ZHI7DQorCWtleS5zcmMgPSBydC0+cnRfc3BlY19kc3Q7DQorCWtleS50b3Mg PSBSVF9UT1Moc2tiLT5uaC5pcGgtPnRvcyk7DQorCQ0KKwlpZiAoaXBfcm91 dGVfb3V0cHV0X2tleSgmcnQsICZrZXkpKQ0KIAkJcmV0dXJuOw0KIA0KIAkv KiBBbmQgbGV0IElQIGRvIGFsbCB0aGUgaGFyZCB3b3JrLg0KZGlmZiAtdXJO IC1YIC91c3Ivc3JjL21pc2MveGtkaWZmIGxpbnV4LTIuNS43Lm9yaWcvbmV0 L2lwdjQvaXBpcC5jIGxpbnV4LTIuNS43LXcxL25ldC9pcHY0L2lwaXAuYw0K LS0tIGxpbnV4LTIuNS43Lm9yaWcvbmV0L2lwdjQvaXBpcC5jCUZyaSBPY3Qg MjYgMTU6MDk6MzggMjAwMQ0KKysrIGxpbnV4LTIuNS43LXcxL25ldC9pcHY0 L2lwaXAuYwlTdW4gTWFyIDI0IDIxOjUyOjE0IDIwMDINCkBAIC0zNTYsNiAr MzU2LDcgQEANCiAJaW50IHJlbF9pbmZvID0gMDsNCiAJc3RydWN0IHNrX2J1 ZmYgKnNrYjI7DQogCXN0cnVjdCBydGFibGUgKnJ0Ow0KKwlzdHJ1Y3QgcnRf a2V5IGtleSA9IHsgMCB9Ow0KIA0KIAlpZiAobGVuIDwgaGxlbiArIHNpemVv ZihzdHJ1Y3QgaXBoZHIpKQ0KIAkJcmV0dXJuOw0KQEAgLTQxNyw3ICs0MTgs OSBAQA0KIAlza2IyLT5uaC5yYXcgPSBza2IyLT5kYXRhOw0KIA0KIAkvKiBU cnkgdG8gZ3Vlc3MgaW5jb21pbmcgaW50ZXJmYWNlICovDQotCWlmIChpcF9y b3V0ZV9vdXRwdXQoJnJ0LCBlaXBoLT5zYWRkciwgMCwgUlRfVE9TKGVpcGgt PnRvcyksIDApKSB7DQorCWtleS5kc3QgPSBlaXBoLT5zYWRkcjsNCisJa2V5 LnRvcyA9IFJUX1RPUyhlaXBoLT50b3MpOw0KKwlpZiAoaXBfcm91dGVfb3V0 cHV0X2tleSgmcnQsICZrZXkpKSB7DQogCQlrZnJlZV9za2Ioc2tiMik7DQog CQlyZXR1cm47DQogCX0NCkBAIC00MjcsNyArNDMwLDkgQEANCiAJaWYgKHJ0 LT5ydF9mbGFncyZSVENGX0xPQ0FMKSB7DQogCQlpcF9ydF9wdXQocnQpOw0K IAkJcnQgPSBOVUxMOw0KLQkJaWYgKGlwX3JvdXRlX291dHB1dCgmcnQsIGVp cGgtPmRhZGRyLCBlaXBoLT5zYWRkciwgZWlwaC0+dG9zLCAwKSB8fA0KKwkJ a2V5LmRzdCA9IGVpcGgtPmRhZGRyOw0KKwkJa2V5LnNyYyA9IGVpcGgtPnNh ZGRyOw0KKwkJaWYgKGlwX3JvdXRlX291dHB1dF9rZXkoJnJ0LCAma2V5KSB8 fA0KIAkJICAgIHJ0LT51LmRzdC5kZXYtPnR5cGUgIT0gQVJQSFJEX0lQR1JF KSB7DQogCQkJaXBfcnRfcHV0KHJ0KTsNCiAJCQlrZnJlZV9za2Ioc2tiMik7 DQpAQCAtNTM4LDYgKzU0Myw3IEBADQogCWludCAgICBtYXhfaGVhZHJvb207 CQkJLyogVGhlIGV4dHJhIGhlYWRlciBzcGFjZSBuZWVkZWQgKi8NCiAJdTMy ICAgIGRzdCA9IHRpcGgtPmRhZGRyOw0KIAlpbnQgICAgbXR1Ow0KKwlzdHJ1 Y3QgcnRfa2V5IGtleSA9IHsgMCB9Ow0KIA0KIAlpZiAodHVubmVsLT5yZWN1 cnNpb24rKykgew0KIAkJdHVubmVsLT5zdGF0LmNvbGxpc2lvbnMrKzsNCkBA IC01NjAsNyArNTY2LDExIEBADQogCQkJZ290byB0eF9lcnJvcl9pY21wOw0K IAl9DQogDQotCWlmIChpcF9yb3V0ZV9vdXRwdXQoJnJ0LCBkc3QsIHRpcGgt PnNhZGRyLCBSVF9UT1ModG9zKSwgdHVubmVsLT5wYXJtcy5saW5rKSkgew0K KwlrZXkuZHN0ID0gZHN0Ow0KKwlrZXkuc3JjID0gdGlwaC0+c2FkZHI7DQor CWtleS50b3MgPSBSVF9UT1ModG9zKTsNCisJa2V5Lm9pZiA9IHR1bm5lbC0+ cGFybXMubGluazsNCisJaWYgKGlwX3JvdXRlX291dHB1dF9rZXkoJnJ0LCAm a2V5KSkgew0KIAkJdHVubmVsLT5zdGF0LnR4X2NhcnJpZXJfZXJyb3JzKys7 DQogCQlnb3RvIHR4X2Vycm9yX2ljbXA7DQogCX0NCkBAIC04MTksNyArODI5 LDkgQEANCiANCiAJaWYgKGlwaC0+ZGFkZHIpIHsNCiAJCXN0cnVjdCBydGFi bGUgKnJ0Ow0KLQkJaWYgKCFpcF9yb3V0ZV9vdXRwdXQoJnJ0LCBpcGgtPmRh ZGRyLCBpcGgtPnNhZGRyLCBSVF9UT1MoaXBoLT50b3MpLCB0dW5uZWwtPnBh cm1zLmxpbmspKSB7DQorCQlzdHJ1Y3QgcnRfa2V5IGtleSA9IHsgZHN0Omlw aC0+ZGFkZHIsIHNyYzppcGgtPnNhZGRyLA0KKwkJCQkgICAgIHRvczpSVF9U T1MoaXBoLT50b3MpLCBvaWY6dHVubmVsLT5wYXJtcy5saW5rIH07DQorCQlp ZiAoIWlwX3JvdXRlX291dHB1dF9rZXkoJnJ0LCAma2V5KSkgew0KIAkJCXRk ZXYgPSBydC0+dS5kc3QuZGV2Ow0KIAkJCWlwX3J0X3B1dChydCk7DQogCQl9 DQpkaWZmIC11ck4gLVggL3Vzci9zcmMvbWlzYy94a2RpZmYgbGludXgtMi41 Ljcub3JpZy9uZXQvaXB2NC9pcG1yLmMgbGludXgtMi41LjctdzEvbmV0L2lw djQvaXBtci5jDQotLS0gbGludXgtMi41Ljcub3JpZy9uZXQvaXB2NC9pcG1y LmMJU3VuIE1hciAyNCAxMjozMDowMCAyMDAyDQorKysgbGludXgtMi41Ljct dzEvbmV0L2lwdjQvaXBtci5jCVN1biBNYXIgMjQgMTU6MTI6MTUgMjAwMg0K QEAgLTExNDEsMTEgKzExNDEsMTQgQEANCiAjZW5kaWYNCiANCiAJaWYgKHZp Zi0+ZmxhZ3MmVklGRl9UVU5ORUwpIHsNCi0JCWlmIChpcF9yb3V0ZV9vdXRw dXQoJnJ0LCB2aWYtPnJlbW90ZSwgdmlmLT5sb2NhbCwgUlRfVE9TKGlwaC0+ dG9zKSwgdmlmLT5saW5rKSkNCisJCXN0cnVjdCBydF9rZXkga2V5ID0geyBk c3Q6dmlmLT5yZW1vdGUsIHNyYzp2aWYtPmxvY2FsLA0KKwkJICAgICAgICAg ICAgICAgICAgICAgIHRvczpSVF9UT1MoaXBoLT50b3MpLCBvaWY6dmlmLT5s aW5rIH07DQorCQlpZiAoaXBfcm91dGVfb3V0cHV0X2tleSgmcnQsICZrZXkp KQ0KIAkJCXJldHVybjsNCiAJCWVuY2FwID0gc2l6ZW9mKHN0cnVjdCBpcGhk cik7DQogCX0gZWxzZSB7DQotCQlpZiAoaXBfcm91dGVfb3V0cHV0KCZydCwg aXBoLT5kYWRkciwgMCwgUlRfVE9TKGlwaC0+dG9zKSwgdmlmLT5saW5rKSkN CisJCXN0cnVjdCBydF9rZXkga2V5ID0geyBkc3Q6aXBoLT5kYWRkciwgdG9z OlJUX1RPUyhpcGgtPnRvcyksIG9pZjp2aWYtPmxpbmsgfTsNCisJCWlmIChp cF9yb3V0ZV9vdXRwdXRfa2V5KCZydCwgJmtleSkpDQogCQkJcmV0dXJuOw0K IAl9DQogDQpkaWZmIC11ck4gLVggL3Vzci9zcmMvbWlzYy94a2RpZmYgbGlu dXgtMi41Ljcub3JpZy9uZXQvaXB2NC9uZXRmaWx0ZXIvaXBfZndfY29tcGF0 X21hc3EuYyBsaW51eC0yLjUuNy13MS9uZXQvaXB2NC9uZXRmaWx0ZXIvaXBf ZndfY29tcGF0X21hc3EuYw0KLS0tIGxpbnV4LTIuNS43Lm9yaWcvbmV0L2lw djQvbmV0ZmlsdGVyL2lwX2Z3X2NvbXBhdF9tYXNxLmMJU3VuIE1hciAyNCAx MjoyNDo0OSAyMDAyDQorKysgbGludXgtMi41LjctdzEvbmV0L2lwdjQvbmV0 ZmlsdGVyL2lwX2Z3X2NvbXBhdF9tYXNxLmMJU3VuIE1hciAyNCAyMDozNTow MSAyMDAyDQpAQCAtNzAsMTAgKzcwLDExIEBADQogCQl1X2ludDMyX3QgbmV3 c3JjOw0KIAkJc3RydWN0IHJ0YWJsZSAqcnQ7DQogCQlzdHJ1Y3QgaXBfbmF0 X211bHRpX3JhbmdlIHJhbmdlOw0KKwkJc3RydWN0IHJ0X2tleSBrZXkgPSB7 IGRzdDppcGgtPmRhZGRyIH07DQogDQogCQkvKiBQYXNzIDAgaW5zdGVhZCBv ZiBzYWRkciwgc2luY2UgaXQncyBnb2luZyB0byBiZSBjaGFuZ2VkDQogCQkg ICBhbnl3YXkuICovDQotCQlpZiAoaXBfcm91dGVfb3V0cHV0KCZydCwgaXBo LT5kYWRkciwgMCwgMCwgMCkgIT0gMCkgew0KKwkJaWYgKGlwX3JvdXRlX291 dHB1dF9rZXkoJnJ0LCAma2V5KSAhPSAwKSB7DQogCQkJREVCVUdQKCJpcG5h dF9ydWxlX21hc3F1ZXJhZGU6IENhbid0IHJlcm91dGUuXG4iKTsNCiAJCQly ZXR1cm4gTkZfRFJPUDsNCiAJCX0NCmRpZmYgLXVyTiAtWCAvdXNyL3NyYy9t aXNjL3hrZGlmZiBsaW51eC0yLjUuNy5vcmlnL25ldC9pcHY0L25ldGZpbHRl ci9pcF9uYXRfY29yZS5jIGxpbnV4LTIuNS43LXcxL25ldC9pcHY0L25ldGZp bHRlci9pcF9uYXRfY29yZS5jDQotLS0gbGludXgtMi41Ljcub3JpZy9uZXQv aXB2NC9uZXRmaWx0ZXIvaXBfbmF0X2NvcmUuYwlTdW4gTWFyIDI0IDEyOjMw OjAwIDIwMDINCisrKyBsaW51eC0yLjUuNy13MS9uZXQvaXB2NC9uZXRmaWx0 ZXIvaXBfbmF0X2NvcmUuYwlTdW4gTWFyIDI0IDIwOjM0OjUzIDIwMDINCkBA IC0yMDQsOSArMjA0LDEwIEBADQogZG9fZXh0cmFfbWFuZ2xlKHVfaW50MzJf dCB2YXJfaXAsIHVfaW50MzJfdCAqb3RoZXJfaXBwKQ0KIHsNCiAJc3RydWN0 IHJ0YWJsZSAqcnQ7DQorCXN0cnVjdCBydF9rZXkga2V5ID0geyBkc3Q6dmFy X2lwIH07DQogDQogCS8qIEZJWE1FOiBJUFRPU19UT1MoaXBoLT50b3MpIC0t UlIgKi8NCi0JaWYgKGlwX3JvdXRlX291dHB1dCgmcnQsIHZhcl9pcCwgMCwg MCwgMCkgIT0gMCkgew0KKwlpZiAoaXBfcm91dGVfb3V0cHV0X2tleSgmcnQs ICZrZXkpICE9IDApIHsNCiAJCURFQlVHUCgiZG9fZXh0cmFfbWFuZ2xlOiBD YW4ndCBnZXQgcm91dGUgdG8gJXUuJXUuJXUuJXVcbiIsDQogCQkgICAgICAg TklQUVVBRCh2YXJfaXApKTsNCiAJCXJldHVybiAwOw0KZGlmZiAtdXJOIC1Y IC91c3Ivc3JjL21pc2MveGtkaWZmIGxpbnV4LTIuNS43Lm9yaWcvbmV0L2lw djQvbmV0ZmlsdGVyL2lwdF9NSVJST1IuYyBsaW51eC0yLjUuNy13MS9uZXQv aXB2NC9uZXRmaWx0ZXIvaXB0X01JUlJPUi5jDQotLS0gbGludXgtMi41Ljcu b3JpZy9uZXQvaXB2NC9uZXRmaWx0ZXIvaXB0X01JUlJPUi5jCVdlZCBKYW4g MTYgMDE6MjQ6NTIgMjAwMg0KKysrIGxpbnV4LTIuNS43LXcxL25ldC9pcHY0 L25ldGZpbHRlci9pcHRfTUlSUk9SLmMJU3VuIE1hciAyNCAyMDozNzowNSAy MDAyDQpAQCAtNDUsMTMgKzQ1LDEyIEBADQogew0KICAgICAgICAgc3RydWN0 IGlwaGRyICppcGggPSBza2ItPm5oLmlwaDsNCiAJc3RydWN0IHJ0YWJsZSAq cnQ7DQorCXN0cnVjdCBydF9rZXkga2V5ID0geyBkc3Q6aXBoLT5zYWRkciwg c3JjOmlwaC0+ZGFkZHIsDQorCSAgICAgICAgICAgICAgICAgICAgICB0b3M6 UlRfVE9TKGlwaC0+dG9zKSB8IFJUT19DT05OIH07DQogDQogCS8qIEJhY2t3 YXJkcyAqLw0KLQlpZiAoaXBfcm91dGVfb3V0cHV0KCZydCwgaXBoLT5zYWRk ciwgaXBoLT5kYWRkciwNCi0JCQkgICAgUlRfVE9TKGlwaC0+dG9zKSB8IFJU T19DT05OLA0KLQkJCSAgICAwKSkgew0KKwlpZiAoaXBfcm91dGVfb3V0cHV0 X2tleSgmcnQsICZrZXkpKQ0KIAkJcmV0dXJuIDA7DQotCX0NCiANCiAJLyog Y2hlY2sgaWYgdGhlIGludGVyZmFjZSB3ZSBhcmUgbGVhdmluZyBieSBpcyB0 aGUgc2FtZSBhcyB0aGUNCiAgICAgICAgICAgIG9uZSB3ZSBhcnJpdmVkIG9u ICovDQpkaWZmIC11ck4gLVggL3Vzci9zcmMvbWlzYy94a2RpZmYgbGludXgt Mi41Ljcub3JpZy9uZXQvaXB2NC9uZXRmaWx0ZXIvaXB0X1JFSkVDVC5jIGxp bnV4LTIuNS43LXcxL25ldC9pcHY0L25ldGZpbHRlci9pcHRfUkVKRUNULmMN Ci0tLSBsaW51eC0yLjUuNy5vcmlnL25ldC9pcHY0L25ldGZpbHRlci9pcHRf UkVKRUNULmMJU3VuIE1hciAyNCAxMjozMDowMCAyMDAyDQorKysgbGludXgt Mi41LjctdzEvbmV0L2lwdjQvbmV0ZmlsdGVyL2lwdF9SRUpFQ1QuYwlTdW4g TWFyIDI0IDIwOjQwOjEzIDIwMDINCkBAIC00MSw2ICs0MSw3IEBADQogCXVu c2lnbmVkIGludCBvdGNwbGVuOw0KIAl1X2ludDE2X3QgdG1wOw0KIAlpbnQg bmVlZHNfYWNrOw0KKwlzdHJ1Y3QgcnRfa2V5IGtleSA9IHsgMCB9Ow0KIA0K IAkvKiBJUCBoZWFkZXIgY2hlY2tzOiBmcmFnbWVudCwgdG9vIHNob3J0LiAq Lw0KIAlpZiAob2xkc2tiLT5uaC5pcGgtPmZyYWdfb2ZmICYgaHRvbnMoSVBf T0ZGU0VUKQ0KQEAgLTEyNywxMCArMTI4LDExIEBADQogCQkJCQkgICBuc2ti LT5uaC5pcGgtPmlobCk7DQogDQogCS8qIFJvdXRpbmc6IGlmIG5vdCBoZWFk ZWQgZm9yIHVzLCByb3V0ZSB3b24ndCBsaWtlIHNvdXJjZSAqLw0KLQlpZiAo aXBfcm91dGVfb3V0cHV0KCZydCwgbnNrYi0+bmguaXBoLT5kYWRkciwNCi0J CQkgICAgbG9jYWwgPyBuc2tiLT5uaC5pcGgtPnNhZGRyIDogMCwNCi0JCQkg ICAgUlRfVE9TKG5za2ItPm5oLmlwaC0+dG9zKSB8IFJUT19DT05OLA0KLQkJ CSAgICAwKSAhPSAwKQ0KKwlrZXkuZHN0ID0gbnNrYi0+bmguaXBoLT5kYWRk cjsNCisJa2V5LnNyYyA9IGxvY2FsID8gbnNrYi0+bmguaXBoLT5zYWRkciA6 IDA7DQorCWtleS50b3MgPSBSVF9UT1MobnNrYi0+bmguaXBoLT50b3MpIHwg UlRPX0NPTk47DQorCQ0KKwlpZiAoaXBfcm91dGVfb3V0cHV0X2tleSgmcnQs ICZrZXkpICE9IDApDQogCQlnb3RvIGZyZWVfbnNrYjsNCiANCiAJZHN0X3Jl bGVhc2UobnNrYi0+ZHN0KTsNCkBAIC0xNjAsNiArMTYyLDcgQEANCiAJaW50 IGhoX2xlbiwgbGVuZ3RoOw0KIAlzdHJ1Y3QgcnRhYmxlICpydCA9IChzdHJ1 Y3QgcnRhYmxlKilza2JfaW4tPmRzdDsNCiAJdW5zaWduZWQgY2hhciAqZGF0 YTsNCisJc3RydWN0IHJ0X2tleSBrZXkgPSB7IDAgfTsNCiANCiAJaWYgKCFy dCkNCiAJCXJldHVybjsNCkBAIC0yMDMsNyArMjA2LDExIEBADQogDQogCXRv cyA9IChpcGgtPnRvcyAmIElQVE9TX1RPU19NQVNLKSB8IElQVE9TX1BSRUNf SU5URVJORVRDT05UUk9MOw0KIA0KLQlpZiAoaXBfcm91dGVfb3V0cHV0KCZy dCwgaXBoLT5zYWRkciwgc2FkZHIsIFJUX1RPUyh0b3MpLCAwKSkNCisJa2V5 LmRzdCA9IGlwaC0+c2FkZHI7DQorCWtleS5zcmMgPSBzYWRkcjsNCisJa2V5 LnRvcyA9IFJUX1RPUyh0b3MpOw0KKwkNCisJaWYgKGlwX3JvdXRlX291dHB1 dF9rZXkoJnJ0LCAma2V5KSkNCiAJCXJldHVybjsNCiANCiAJLyogUkZDIHNh eXMgcmV0dXJuIGFzIG11Y2ggYXMgd2UgY2FuIHdpdGhvdXQgZXhjZWVkaW5n IDU3NiBieXRlcy4gKi8NCmRpZmYgLXVyTiAtWCAvdXNyL3NyYy9taXNjL3hr ZGlmZiBsaW51eC0yLjUuNy5vcmlnL25ldC9pcHY0L3Jhdy5jIGxpbnV4LTIu NS43LXcxL25ldC9pcHY0L3Jhdy5jDQotLS0gbGludXgtMi41Ljcub3JpZy9u ZXQvaXB2NC9yYXcuYwlTdW4gTWFyIDI0IDEyOjMwOjAwIDIwMDINCisrKyBs aW51eC0yLjUuNy13MS9uZXQvaXB2NC9yYXcuYwlTdW4gTWFyIDI0IDE1OjA5 OjU5IDIwMDINCkBAIC0zMTUsNiArMzE1LDcgQEANCiAJdTMyIGRhZGRyOw0K IAl1OCAgdG9zOw0KIAlpbnQgZXJyOw0KKwlzdHJ1Y3QgcnRfa2V5IGtleSA9 IHsgMCB9Ow0KIA0KIAkvKiBUaGlzIGNoZWNrIGlzIE9OTFkgdG8gY2hlY2sg Zm9yIGFyaXRobWV0aWMgb3ZlcmZsb3cNCiAJICAgb24gaW50ZWdlcighKSBs ZW4uIE5vdCBtb3JlISBSZWFsIGNoZWNrIHdpbGwgYmUgbWFkZQ0KQEAgLTQx Miw3ICs0MTMsMTIgQEANCiAJCQlyZmguc2FkZHIgPSBpbmV0LT5tY19hZGRy Ow0KIAl9DQogDQotCWVyciA9IGlwX3JvdXRlX291dHB1dCgmcnQsIGRhZGRy LCByZmguc2FkZHIsIHRvcywgaXBjLm9pZik7DQorCWtleS5kc3QgPSBkYWRk cjsNCisJa2V5LnNyYyA9IHJmaC5zYWRkcjsNCisJa2V5LnRvcyA9IHRvczsN CisJa2V5Lm9pZiA9IGlwYy5vaWY7DQorDQorCWVyciA9IGlwX3JvdXRlX291 dHB1dF9rZXkoJnJ0LCAma2V5KTsNCiANCiAJaWYgKGVycikNCiAJCWdvdG8g ZG9uZTsNCmRpZmYgLXVyTiAtWCAvdXNyL3NyYy9taXNjL3hrZGlmZiBsaW51 eC0yLjUuNy5vcmlnL25ldC9pcHY0L3JvdXRlLmMgbGludXgtMi41LjctdzEv bmV0L2lwdjQvcm91dGUuYw0KLS0tIGxpbnV4LTIuNS43Lm9yaWcvbmV0L2lw djQvcm91dGUuYwlTdW4gTWFyIDI0IDEyOjI0OjQ5IDIwMDINCisrKyBsaW51 eC0yLjUuNy13MS9uZXQvaXB2NC9yb3V0ZS5jCVN1biBNYXIgMjQgMjA6NDg6 NTYgMjAwMg0KQEAgLTIxNTEsMTAgKzIxNTEsMTAgQEANCiAJCWlmICghZXJy ICYmIHJ0LT51LmRzdC5lcnJvcikNCiAJCQllcnIgPSAtcnQtPnUuZHN0LmVy cm9yOw0KIAl9IGVsc2Ugew0KLQkJaW50IG9pZiA9IDA7DQorCQlzdHJ1Y3Qg cnRfa2V5IGtleSA9IHsgZHN0OmRzdCwgc3JjOnNyYywgdG9zOnJ0bS0+cnRt X3RvcyB9Ow0KIAkJaWYgKHJ0YVtSVEFfT0lGIC0gMV0pDQotCQkJbWVtY3B5 KCZvaWYsIFJUQV9EQVRBKHJ0YVtSVEFfT0lGIC0gMV0pLCBzaXplb2YoaW50 KSk7DQotCQllcnIgPSBpcF9yb3V0ZV9vdXRwdXQoJnJ0LCBkc3QsIHNyYywg cnRtLT5ydG1fdG9zLCBvaWYpOw0KKwkJCW1lbWNweSgma2V5Lm9pZiwgUlRB X0RBVEEocnRhW1JUQV9PSUYgLSAxXSksIHNpemVvZihpbnQpKTsNCisJCWVy ciA9IGlwX3JvdXRlX291dHB1dF9rZXkoJnJ0LCAma2V5KTsNCiAJfQ0KIAlp ZiAoZXJyKSB7DQogCQlrZnJlZV9za2Ioc2tiKTsNCmRpZmYgLXVyTiAtWCAv dXNyL3NyYy9taXNjL3hrZGlmZiBsaW51eC0yLjUuNy5vcmlnL25ldC9pcHY0 L3N5bmNvb2tpZXMuYyBsaW51eC0yLjUuNy13MS9uZXQvaXB2NC9zeW5jb29r aWVzLmMNCi0tLSBsaW51eC0yLjUuNy5vcmlnL25ldC9pcHY0L3N5bmNvb2tp ZXMuYwlTdW4gTWFyIDI0IDEyOjI2OjE5IDIwMDINCisrKyBsaW51eC0yLjUu Ny13MS9uZXQvaXB2NC9zeW5jb29raWVzLmMJU3VuIE1hciAyNCAyMDozMjo1 NSAyMDAyDQpAQCAtMTIxLDYgKzEyMSw3IEBADQogCWludCBtc3M7IA0KIAlz dHJ1Y3QgcnRhYmxlICpydDsgDQogCV9fdTggcmN2X3dzY2FsZTsNCisJc3Ry dWN0IHJ0X2tleSBrZXkgPSB7IDAgfTsNCiANCiAJaWYgKCFzeXNjdGxfdGNw X3N5bmNvb2tpZXMgfHwgIXNrYi0+aC50aC0+YWNrKQ0KIAkJZ290byBvdXQ7 DQpAQCAtMTczLDEyICsxNzQsMTEgQEANCiAJICogaGFzbid0IGNoYW5nZWQg c2luY2Ugd2UgcmVjZWl2ZWQgdGhlIG9yaWdpbmFsIHN5biwgYnV0IEkgc2Vl DQogCSAqIG5vIGVhc3kgd2F5IHRvIGRvIHRoaXMuIA0KIAkgKi8NCi0JaWYg KGlwX3JvdXRlX291dHB1dCgmcnQsDQotCQkJICAgIG9wdCAmJiANCi0JCQkg ICAgb3B0LT5zcnIgPyBvcHQtPmZhZGRyIDogcmVxLT5hZi52NF9yZXEucm10 X2FkZHIsDQotCQkJICAgIHJlcS0+YWYudjRfcmVxLmxvY19hZGRyLA0KLQkJ CSAgICBSVF9DT05OX0ZMQUdTKHNrKSwNCi0JCQkgICAgMCkpIHsgDQorCWtl eS5kc3QgPSBvcHQgJiYgb3B0LT5zcnIgPyBvcHQtPmZhZGRyIDogcmVxLT5h Zi52NF9yZXEucm10X2FkZHI7DQorCWtleS5zcmMgPSByZXEtPmFmLnY0X3Jl cS5sb2NfYWRkcjsNCisJa2V5LnRvcyA9IFJUX0NPTk5fRkxBR1Moc2spOw0K KwkNCisJaWYgKGlwX3JvdXRlX291dHB1dF9rZXkoJnJ0LCAma2V5KSkgew0K IAkJdGNwX29wZW5yZXFfZnJlZShyZXEpOw0KIAkJZ290byBvdXQ7IA0KIAl9 DQpkaWZmIC11ck4gLVggL3Vzci9zcmMvbWlzYy94a2RpZmYgbGludXgtMi41 Ljcub3JpZy9uZXQvaXB2NC90Y3BfaXB2NC5jIGxpbnV4LTIuNS43LXcxL25l dC9pcHY0L3RjcF9pcHY0LmMNCi0tLSBsaW51eC0yLjUuNy5vcmlnL25ldC9p cHY0L3RjcF9pcHY0LmMJU3VuIE1hciAyNCAxMjozMDowMCAyMDAyDQorKysg bGludXgtMi41LjctdzEvbmV0L2lwdjQvdGNwX2lwdjQuYwlTdW4gTWFyIDI0 IDE1OjIwOjIwIDIwMDINCkBAIC0xMTY3LDE0ICsxMTY3LDEyIEBADQogc3Rh dGljIHN0cnVjdCBkc3RfZW50cnkqIHRjcF92NF9yb3V0ZV9yZXEoc3RydWN0 IHNvY2sgKnNrLCBzdHJ1Y3Qgb3Blbl9yZXF1ZXN0ICpyZXEpDQogew0KIAlz dHJ1Y3QgcnRhYmxlICpydDsNCi0Jc3RydWN0IGlwX29wdGlvbnMgKm9wdDsN Ci0NCi0Jb3B0ID0gcmVxLT5hZi52NF9yZXEub3B0Ow0KLQlpZihpcF9yb3V0 ZV9vdXRwdXQoJnJ0LCAoKG9wdCAmJiBvcHQtPnNycikgPw0KLQkJCQkgb3B0 LT5mYWRkciA6DQotCQkJCSByZXEtPmFmLnY0X3JlcS5ybXRfYWRkciksDQot CQkJICAgcmVxLT5hZi52NF9yZXEubG9jX2FkZHIsDQotCQkJICAgUlRfQ09O Tl9GTEFHUyhzayksIHNrLT5ib3VuZF9kZXZfaWYpKSB7DQorCXN0cnVjdCBp cF9vcHRpb25zICpvcHQgPSByZXEtPmFmLnY0X3JlcS5vcHQ7DQorCXN0cnVj dCBydF9rZXkga2V5ID0geyBkc3Q6KChvcHQgJiYgb3B0LT5zcnIpID8gb3B0 LT5mYWRkciA6IHJlcS0+YWYudjRfcmVxLnJtdF9hZGRyKSwNCisJICAgICAg ICAgICAgICAgICAgICAgIHNyYzogcmVxLT5hZi52NF9yZXEubG9jX2FkZHIs DQorCSAgICAgICAgICAgICAgICAgICAgICB0b3M6UlRfQ09OTl9GTEFHUyhz ayksIG9pZjpzay0+Ym91bmRfZGV2X2lmIH07DQorCQ0KKwlpZihpcF9yb3V0 ZV9vdXRwdXRfa2V5KCZydCwgJmtleSkpIHsNCiAJCUlQX0lOQ19TVEFUU19C SChJcE91dE5vUm91dGVzKTsNCiAJCXJldHVybiBOVUxMOw0KIAl9DQpAQCAt MTc5NiwyMCArMTc5NCwyMyBAQA0KIHsNCiAJc3RydWN0IGluZXRfb3B0ICpp bmV0ID0gaW5ldF9zayhzayk7DQogCXN0cnVjdCBydGFibGUgKnJ0ID0gKHN0 cnVjdCBydGFibGUgKilfX3NrX2RzdF9jaGVjayhzaywgMCk7DQotCXUzMiBk YWRkcjsNCiAJaW50IGVycjsNCisJc3RydWN0IHJ0X2tleSBrZXkgPSB7IDAg fTsNCiANCiAJLyogUm91dGUgaXMgT0ssIG5vdGhpbmcgdG8gZG8uICovDQog CWlmIChydCAhPSBOVUxMKQ0KIAkJcmV0dXJuIDA7DQogDQogCS8qIFJlcm91 dGUuICovDQotCWRhZGRyID0gaW5ldC0+ZGFkZHI7DQorCWtleS5kc3QgPSBp bmV0LT5kYWRkcjsNCiAJaWYgKGluZXQtPm9wdCAmJiBpbmV0LT5vcHQtPnNy cikNCi0JCWRhZGRyID0gaW5ldC0+b3B0LT5mYWRkcjsNCisJCWtleS5kc3Qg PSBpbmV0LT5vcHQtPmZhZGRyOw0KIA0KLQllcnIgPSBpcF9yb3V0ZV9vdXRw dXQoJnJ0LCBkYWRkciwgaW5ldC0+c2FkZHIsDQotCQkJICAgICAgUlRfQ09O Tl9GTEFHUyhzayksIHNrLT5ib3VuZF9kZXZfaWYpOw0KKwlrZXkuc3JjID0g aW5ldC0+c2FkZHI7DQorCWtleS50b3MgPSBSVF9DT05OX0ZMQUdTKHNrKTsN CisJa2V5Lm9pZiA9IHNrLT5ib3VuZF9kZXZfaWY7DQorCQ0KKwllcnIgPSBp cF9yb3V0ZV9vdXRwdXRfa2V5KCZydCwgJmtleSk7DQogCWlmICghZXJyKSB7 DQogCQlfX3NrX2RzdF9zZXQoc2ssICZydC0+dS5kc3QpOw0KIAkJc2stPnJv dXRlX2NhcHMgPSBydC0+dS5kc3QuZGV2LT5mZWF0dXJlczsNCmRpZmYgLXVy TiAtWCAvdXNyL3NyYy9taXNjL3hrZGlmZiBsaW51eC0yLjUuNy5vcmlnL25l dC9pcHY0L3VkcC5jIGxpbnV4LTIuNS43LXcxL25ldC9pcHY0L3VkcC5jDQot LS0gbGludXgtMi41Ljcub3JpZy9uZXQvaXB2NC91ZHAuYwlTdW4gTWFyIDI0 IDEyOjMwOjAwIDIwMDINCisrKyBsaW51eC0yLjUuNy13MS9uZXQvaXB2NC91 ZHAuYwlTdW4gTWFyIDI0IDIwOjU1OjA0IDIwMDINCkBAIC01MjgsNyArNTI4 LDkgQEANCiAJCXJ0ID0gKHN0cnVjdCBydGFibGUqKXNrX2RzdF9jaGVjayhz aywgMCk7DQogDQogCWlmIChydCA9PSBOVUxMKSB7DQotCQllcnIgPSBpcF9y b3V0ZV9vdXRwdXQoJnJ0LCBkYWRkciwgdWZoLnNhZGRyLCB0b3MsIGlwYy5v aWYpOw0KKwkJc3RydWN0IHJ0X2tleSBrZXkgPSB7IGRzdDpkYWRkciwgc3Jj OnVmaC5zYWRkciwgdG9zOnRvcywgb2lmOmlwYy5vaWYgfTsNCisJCQ0KKwkJ ZXJyID0gaXBfcm91dGVfb3V0cHV0X2tleSgmcnQsICZrZXkpOw0KIAkJaWYg KGVycikNCiAJCQlnb3RvIG91dDsNCiANCmRpZmYgLXVyTiAtWCAvdXNyL3Ny Yy9taXNjL3hrZGlmZiBsaW51eC0yLjUuNy5vcmlnL25ldC9pcHY2L3NpdC5j IGxpbnV4LTIuNS43LXcxL25ldC9pcHY2L3NpdC5jDQotLS0gbGludXgtMi41 Ljcub3JpZy9uZXQvaXB2Ni9zaXQuYwlUaHUgT2N0IDExIDE5OjE4OjAwIDIw MDENCisrKyBsaW51eC0yLjUuNy13MS9uZXQvaXB2Ni9zaXQuYwlTdW4gTWFy IDI0IDIwOjQzOjMxIDIwMDINCkBAIC00NjMsNiArNDYzLDcgQEANCiAJaW50 ICAgIG10dTsNCiAJc3RydWN0IGluNl9hZGRyICphZGRyNjsJDQogCWludCBh ZGRyX3R5cGU7DQorCXN0cnVjdCBydF9rZXkga2V5ID0geyAwIH07DQogDQog CWlmICh0dW5uZWwtPnJlY3Vyc2lvbisrKSB7DQogCQl0dW5uZWwtPnN0YXQu Y29sbGlzaW9ucysrOw0KQEAgLTUwMCw4ICs1MDEsMTMgQEANCiANCiAJCWRz dCA9IGFkZHI2LT5zNl9hZGRyMzJbM107DQogCX0NCi0NCi0JaWYgKGlwX3Jv dXRlX291dHB1dCgmcnQsIGRzdCwgdGlwaC0+c2FkZHIsIFJUX1RPUyh0b3Mp LCB0dW5uZWwtPnBhcm1zLmxpbmspKSB7DQorCQ0KKwlrZXkuZHN0ID0gZHN0 Ow0KKwlrZXkuc3JjID0gdGlwaC0+c2FkZHI7DQorCWtleS50b3MgPSBSVF9U T1ModG9zKTsNCisJa2V5Lm9pZiA9IHR1bm5lbC0+cGFybXMubGluazsNCisJ DQorCWlmIChpcF9yb3V0ZV9vdXRwdXRfa2V5KCZydCwgJmtleSkpIHsNCiAJ CXR1bm5lbC0+c3RhdC50eF9jYXJyaWVyX2Vycm9ycysrOw0KIAkJZ290byB0 eF9lcnJvcl9pY21wOw0KIAl9DQpAQCAtNzczLDcgKzc3OSw5IEBADQogDQog CWlmIChpcGgtPmRhZGRyKSB7DQogCQlzdHJ1Y3QgcnRhYmxlICpydDsNCi0J CWlmICghaXBfcm91dGVfb3V0cHV0KCZydCwgaXBoLT5kYWRkciwgaXBoLT5z YWRkciwgUlRfVE9TKGlwaC0+dG9zKSwgdHVubmVsLT5wYXJtcy5saW5rKSkg ew0KKwkJc3RydWN0IHJ0X2tleSBrZXkgPSB7IGRzdDppcGgtPmRhZGRyLCBz cmM6aXBoLT5zYWRkciwNCisJCSAgICAgICAgICAgICAgICAgICAgICB0b3M6 UlRfVE9TKGlwaC0+dG9zKSwgb2lmOnR1bm5lbC0+cGFybXMubGluayB9Ow0K KwkJaWYgKCFpcF9yb3V0ZV9vdXRwdXRfa2V5KCZydCwgJmtleSkpIHsNCiAJ CQl0ZGV2ID0gcnQtPnUuZHN0LmRldjsNCiAJCQlpcF9ydF9wdXQocnQpOw0K IAkJfQ0K --550177381-301911034-1016975646=:24449-- From owner-netdev@oss.sgi.com Sun Mar 24 11:55:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OJtPX11547 for netdev-outgoing; Sun, 24 Mar 2002 11:55:25 -0800 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2OJtIq11543 for ; Sun, 24 Mar 2002 11:55:18 -0800 Received: (qmail 4673 invoked by uid 2001); 24 Mar 2002 19:57:37 -0000 Date: Sun, 24 Mar 2002 20:57:37 +0100 From: Petr Baudis To: Petr Baudis Cc: Pekka Savola , xs26-dev@xs26.net, Jan Oravec , netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: addrconf.c - possible bug Message-ID: <20020324195737.GM1954@pasky.ji.cz> Reply-To: xs26-dev@xs26.net References: <20020323165921.GC1954@pasky.ji.cz> <20020323184451.GD1954@pasky.ji.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020323184451.GD1954@pasky.ji.cz> User-Agent: Mutt/1.5.0i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1929 Lines: 43 Dear diary, on Sat, Mar 23, 2002 at 07:44:51PM CET, I got a letter, where Petr Baudis told me, that... > Dear diary, on Sat, Mar 23, 2002 at 06:08:26PM CET, I got a letter, where Pekka > Savola told me, that... > > On Sat, 23 Mar 2002, Petr Baudis wrote: > > > > I think I've seen something similar to this before, and IIRC it was > > > > caused by the fact that loopback interface had been brought down. > > > > > > > > If loopback has been taken down and is back up, IIRC the addresses of the > > > > interfaces must be "refreshed" (e.g. by also taking the interfaces down > > > > and up). > > > > > > First, sorry for the late reply. > > > > > > The problem is, that we don't do anything with loopback interface at all. > > > Please ask us for any additional informations you need, we'll gladly > > > provide you them. > > > > Perhaps zebra does. You could try stracing the appropriate processes to see > > whether they're doing something nasty; 'tcpdump -n -i lo' might also die if > > loopback is taken down and back up. > > I started the tcpdump there, and we'll see. However, by looking into code, we > found no possibility how would zebra want to mess with loopback. > > Also, we discovered that just taking down and back up any ONE interface will > fix this for ALL other interfaces as well. It failed again and tcpdump still runs happily. Again, taking one of the interfaces down and back up (maybe it's worth mentioning that the machine acts as XS26 PoP, thus it have about 270 interfaces just now up) fixed the problem and the machine started to reply to neighbor solicitations again. -- Petr "Pasky" Baudis * elinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI hacker . Teamwork is essential -- it allows you to blame someone else. . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From owner-netdev@oss.sgi.com Sun Mar 24 14:41:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OMf9B13253 for netdev-outgoing; Sun, 24 Mar 2002 14:41:09 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2OMf5q13250 for ; Sun, 24 Mar 2002 14:41:05 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2OMhMZ16072; Mon, 25 Mar 2002 00:43:22 +0200 Date: Mon, 25 Mar 2002 00:43:22 +0200 (EET) From: Pekka Savola To: netdev@oss.sgi.com cc: kuznet@ms2.inr.ac.ru Subject: IPv6: No NUD for e.g. P-t-P Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 966 Lines: 25 Hello, It appears that in a few cases, Linux IPv6 implementation does not respond to Neighbor Unreachibility Detection packets. This isn't configurable. I noticed this for Point-to-Point links case (IPv6-in-IPv4 tunnel); the code fragments can be seen in ndisc.c by looking for NUD_NOARP. RFC2893 states in 3.8 that if an implementation provides bidirectional tunnels, it MUST at least accept and respond to NUD packets (doesn't do this). It also SHOULD send NUD packets on its own to determine whether the tunnel is down (doesn't do this but this is a bit more questionable). This was triggered by a person noticing NetBSD seems to take down routes to such destinations under some circumstances as the tunnel is deemed to be down. Anything I've missed? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Mon Mar 25 23:36:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q7ae809188 for netdev-outgoing; Mon, 25 Mar 2002 23:36:40 -0800 Received: from hotmail.com (f60.law3.hotmail.com [209.185.241.60]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2Q7aUq09178 for ; Mon, 25 Mar 2002 23:36:30 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 23:38:48 -0800 Received: from 128.233.128.5 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 07:38:47 GMT X-Originating-IP: [128.233.128.5] From: "J K" To: netdev@oss.sgi.com Subject: Re: draining multiple sockets Date: Tue, 26 Mar 2002 07:38:47 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 07:38:48.0686 (UTC) FILETIME=[4477A0E0:01C1D499] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3091 Lines: 88 > >On Fri, Mar 22, 2002 at 12:25:10AM +0000, J K wrote: > > > 2. In practice though, the draining of sockets is like a FCFS > > scheduling discipline!!! > > Which ever socket has data to send, will grab a piece of the > > TCP sk->sndbuf (16KB) and write it out. If the sndbuf is full, > > the process waits a random amount of time (between 2 and 21 > > jiffies) then retries again. >16k=~10 packets, while there is a queue of 100 packets. So I think you will >still achieve balancing. >The *real* experts on this reside on netdev@oss.sgi.com, you may want to >ask >there Alexey, Andi & DaveM are the real gurus. >Regards, > >bert >[LARTC] draining multiple sockets bert hubert ahu@ds9a.nl > Hi, Just thought of sending my query over to you guys, based on the above response I got from the LARTC list. Sorry for this direct mail though! Here is my LARTC question: Could you please correct my understanding if I am wrong? Thanks. - jaika >>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<< Hi, I am looking into the codes of linux kernel(ipv4/tcp.c,tcp_output.c /net/core/dev.c etc.) to find out how multiple sockets are drained on to the network. Here is the picture that I got so far: If there are 'n' sockets with data to send over TCP, then they all supposedly take equal turns draining their data on to the xmit_queue. 1. However, this 'equal turn' (fair) philosophy is guided more in part due to the nature of the TCP behavior under competing flows, than anything else. 2. In practice though, the draining of sockets is like a FCFS scheduling discipline!!! Which ever socket has data to send, will grab a piece of the TCP sk->sndbuf (16KB) and write it out. If the sndbuf is full, the process waits a random amount of time (between 2 and 21 jiffies) then retries again. 3. Once inside the sndbuf, the packet is passed on to the IP level and then to the device level (default device_xmit_queue length of 100 packets for ethernet). At every instant the routines constantly try to push as much data out on to the network (device_xmit_queue) as possible. right? If I am wrong regarding any of the above 3 statements, **please** correct me. socket1 ||||| ---> TCP processing --> IP processing _ \ socket2 \ n/w xmit_queue |||| ---> TCP processing --> IP processing ------> |||||||---> . / . / . / socket n / ||||| ---> TCP processing --> IP processing - - jaika ps: Here is what I gleaned from the sources: in tcp_ipv4.c: sk->sndbuff is initialised to sysctl_tcp_wmem[1]; and in net/ipv4/tcp.c: int sysctl_tcp_wmem[3] = {4*1024, 16*1024, 128*1024}; So I guess the sndbuff is initialised to 16K. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-netdev@oss.sgi.com Tue Mar 26 10:01:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QI1Op02367 for netdev-outgoing; Tue, 26 Mar 2002 10:01:24 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QHxTq01220 for ; Tue, 26 Mar 2002 09:59:29 -0800 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2QI17I15648; Tue, 26 Mar 2002 13:01:07 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HR1LQX0V; Tue, 26 Mar 2002 13:01:08 -0500 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQPL8W16; Tue, 26 Mar 2002 13:01:08 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 2D37053F8; Tue, 26 Mar 2002 13:10:52 -0500 (EST) Message-ID: <3CA0B9AB.F96B83EE@nortelnetworks.com> Date: Tue, 26 Mar 2002 13:10:51 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: is iproute2-2.4.7-now-ss020116-try safe to use? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 678 Lines: 18 We're moving a linux-based project from the 2.2 kernel to 2.4, and one of the components is based on iproute2 (yes, the source is distributed as required). Anyways, after trying some recent versions of iproute2, the only one that compiles cleanly out of the box is iproute2-2.4.7-now-ss020116-try. The "try" makes me a bit nervous, so I was wondering if there are any known issues with this version. Anyone know? Alexey? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Wed Mar 27 00:46:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R8kHZ31700 for netdev-outgoing; Wed, 27 Mar 2002 00:46:17 -0800 Received: from balabit.hu (balabit.bakats.tvnet.hu [195.38.106.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R8k7q31696 for ; Wed, 27 Mar 2002 00:46:10 -0800 Date: Wed, 27 Mar 2002 09:48:25 +0100 From: Balazs Scheidler To: netdev@oss.sgi.com, Harald Welte , netfilter-devel@lists.samba.org Subject: Re: TPROXY and original dest address question Message-ID: <20020327094825.B27766@balabit.hu> References: <20020326162104.C26421@balabit.hu> <20020327085901.D3065@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020327085901.D3065@sunbeam.de.gnumonks.org>; from laforge@gnumonks.org on Wed, Mar 27, 2002 at 08:59:01AM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1982 Lines: 52 Hi, I have the intent to develop real transparent proxy support into the kernel 2.4 series (not a backport of the original 2.2 code) Since at a few places it affects network core I asked the question below on netfilter-devel and they directed me to here. Could you please comment on it? For a reference, the implementation tries to touch the networking code the least possible, so it rewrites destination addresses prior they enter the networking core. Its a simple, stateless DNAT. On Wed, Mar 27, 2002 at 08:59:01AM +0100, Harald Welte wrote: > On Tue, Mar 26, 2002 at 04:21:04PM +0100, Balazs Scheidler wrote: > > Hi, > > > > I found some time to get back to my transparent proxy support for Netfilter. > > cool. We'd really like to see this getting forward. > > > - TPROXY target redirects a session > > > > - the original destination address/port number is stored in the IPCB() part > > of the skb > > > > - as soon as the socket is created this address/port number is copied into > > sk->tp_pinfo.af_tcp (struct tcp_opt) This would happen in tcp_v4_hnd_req() > > > > - this information is queried by the application using a getsockopt call to > > fetch the original destination address, the getsockopt can be implemented > > by registering an nf_sockopt_ops > > > > I'd like to have the core-members advice, is this a good way? Harald? > > This looks fine to me, but I'm not as much into the sockets code as others > are. > > If you want to make it really correct, I'd send that Mail to > the netdev@oss.sgi.com Mailinglist. > > David Miller, Andi Kleen and Alexey Kuznetsov (the networking gods) are hanging > out on that list, so you might get some comments related the 'abuse' of > tp_pinfo.af_tcp and IPCB() from them. > > Based on their reaction you will see if there is a need to change something > or if they would like something like this in the kernel. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 From owner-netdev@oss.sgi.com Wed Mar 27 04:00:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RC0np03159 for netdev-outgoing; Wed, 27 Mar 2002 04:00:49 -0800 Received: from color.sics.se (color.sics.se [193.10.66.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RC0fq03156 for ; Wed, 27 Mar 2002 04:00:42 -0800 Received: from sics.se (pets.sics.se [193.10.65.97]) by color.sics.se (8.9.3/8.9.3) with ESMTP id NAA14432 for ; Wed, 27 Mar 2002 13:03:03 +0100 (MET) env-to () env-from (gabriel@sics.se) Message-ID: <3CA1B4F7.FA937A4F@sics.se> Date: Wed, 27 Mar 2002 13:03:03 +0100 From: Gabriel Paues Reply-To: gabriel@sics.se Organization: SICS X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Interpret the IPv6 header Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1778 Lines: 52 Hi all. I'm writing a module using netfilter that is supposed to show the contents of the IPv6 header (if you wonder why, its an excercise in order to wirte more useful modules later). I have registered a hook that looks like this : static unsigned int ip6hsniff_hook(unsigned int hook, struct sk_buff **pskb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *)){ struct ipv6hdr *ip6; u_int32_t flow; unsigned int version, class, flowlabel; ip6 = (*pskb)->nh.ipv6h; flow = (u_int32_t) (*pskb)->nh.ipv6h; flow = ntohl(flow); flowlabel = flow & 0x000FFFFF; class = (flow & 0x0FF00000) >> 20; version = (flow & 0xF0000000) >> 28; printk("15: payload_len: %d nexthdr: %d Version: %x Class: %x FlowLabel: %x hop_limit: %d ", ip6->payload_len, ip6->nexthdr, version,class,flowlabel,ip6->hop_limit); return NF_ACCEPT; } To try my brand new module a issue this: # ping6 -c 100 fec0::192.168.2.2 -F 00000 PING fec0::192.168.2.2(fec0::c0a8:202) , flow 0x59baa, from fec0::c0a8:102 : 56 data bytes 64 bytes from fec0::c0a8:202: icmp_seq=0 hops=63 time=14.343 msec etc etc etc on another machine. The module prints out things (I see the result with dmesg) but the flowlabel (as far as I can tell) is'nt right. 15: payload_len: 16384 nexthdr: 58 Version: 7 Class: 1 FlowLabel: 68ea0 hop_limit: 64 I must be interpreting the header in the wrong way. I've been staring myself blind at this problem for 2 days now. Does anyone have a clue what I'm doing wrong in the code-snippet above? From owner-netdev@oss.sgi.com Wed Mar 27 17:28:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2S1SxN23087 for netdev-outgoing; Wed, 27 Mar 2002 17:28:59 -0800 Received: from web13003.mail.yahoo.com (web13003.mail.yahoo.com [216.136.174.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2S1Srq23084 for ; Wed, 27 Mar 2002 17:28:53 -0800 Message-ID: <20020328013117.55739.qmail@web13003.mail.yahoo.com> Received: from [65.209.235.11] by web13003.mail.yahoo.com via HTTP; Wed, 27 Mar 2002 17:31:17 PST Date: Wed, 27 Mar 2002 17:31:17 -0800 (PST) From: Yan-Fa Li Subject: Opening more than 65000 sockets To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1688 Lines: 51 Hello, I have a network testing app that would like to open 100K outgoing sockets. I have modified my local range in /proc/sys to allow 2048 - 65000 sockets to be used for out going connections. I have a 2 systems with 2 network cards. Each network card is on a separate LAN: System A: eth0 10.10.12.199 eth1 10.10.14.199 System B: eth0 10.10.12.197 eth1 10.10.14.197 I have 2 servers running on each system at ports: 80 and 443. Each server is bound to the 0.0.0.0 address. Now I start one client and tell it to connect from System A, and tell it to connect to 10.10.12.197 port 80. This client opens 50K sockets. I start another client on System A and tell it to connect to 10.10.14.197 port 443. This client is also told to open 50K sockets. At ~12K sockets it fails. So here's my question, I'm a novice at this sort of thing so I may have done something completely off the wall, but assuming I'm going out a different network interface, why are all socket allocations for outgoing connections appearing to come out of the same pool ? Logically speaking, shouldn't it be possible to use the same socket number for an outgoing socket going out a totally different network interface and thus get another completely unused socket range ? Am I just missing a /proc/sys configuration switch ? Any help you can help or advice would be appreciated. Even a, you can't do that because it's not allowed answer would be better than nothing, because then I'll just go find some more clients and be done with this. Yan __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From owner-netdev@oss.sgi.com Wed Mar 27 22:07:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2S67YS30484 for netdev-outgoing; Wed, 27 Mar 2002 22:07:34 -0800 Received: from grok.yi.org (ip68-3-107-226.ph.ph.cox.net [68.3.107.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2S67Pq30481 for ; Wed, 27 Mar 2002 22:07:25 -0800 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g2S69kL01658; Wed, 27 Mar 2002 23:09:47 -0700 Message-ID: <3CA2B3AA.3050007@candelatech.com> Date: Wed, 27 Mar 2002 23:09:46 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Yan-Fa Li CC: netdev@oss.sgi.com Subject: Re: Opening more than 65000 sockets References: <20020328013117.55739.qmail@web13003.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by grok.yi.org id g2S69kL01658 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2S67Pq30482 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2376 Lines: 74 Try binding locally to the IP of the port out of which you want to send. If you don't specify the local binding (most programs/examples do not), then you will be bound on any/all of them. I haven't actually tried to open that many sockets, but the local bind trick may solve your problem. I'll be interested to hear what you find out! Ben Yan-Fa Li wrote: > Hello, > > I have a network testing app that would like to open 100K outgoing > sockets. I have modified my local range in /proc/sys to > allow 2048 - 65000 sockets to be used for out going connections. > > I have a 2 systems with 2 network cards. Each network card is > on a separate LAN: > > System A: > eth0 10.10.12.199 > eth1 10.10.14.199 > > System B: > eth0 10.10.12.197 > eth1 10.10.14.197 > > I have 2 servers running on each system at ports: 80 and 443. > Each server is bound to the 0.0.0.0 address. > > Now I start one client and tell it to connect from System A, > and tell it to connect to 10.10.12.197 port 80. This client > opens 50K sockets. > > I start another client on System A and tell it to connect > to 10.10.14.197 port 443. This client is also told to open 50K > sockets. At ~12K sockets it fails. > > So here's my question, I'm a novice at this sort of thing so > I may have done something completely off the wall, but assuming > I'm going out a different network interface, why are all socket > allocations for outgoing connections appearing to come out of > the same pool ? > > Logically speaking, shouldn't it be possible to use the same > socket number for an outgoing socket going out a totally > different network interface and thus get another completely > unused socket range ? Am I just missing a /proc/sys configuration > switch ? > > Any help you can help or advice would be appreciated. Even a, > you can't do that because it's not allowed answer would be > better than nothing, because then I'll just go find some more > clients and be done with this. > > Yan > > __________________________________________________ > Do You Yahoo!? > Yahoo! Movies - coverage of the 74th Academy Awards® > http://movies.yahoo.com/ > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Wed Mar 27 23:41:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2S7fxs31264 for netdev-outgoing; Wed, 27 Mar 2002 23:41:59 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2S7frq31261 for ; Wed, 27 Mar 2002 23:41:53 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id CAA72564; Thu, 28 Mar 2002 02:40:52 -0500 Received: from d03nm035.boulder.ibm.com (d03nm035.boulder.ibm.com [9.17.194.35]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2S7iCp140758; Thu, 28 Mar 2002 00:44:12 -0700 From: "Nivedita Singhvi" Importance: Normal Sensitivity: Subject: Re: Opening more than 65000 sockets To: Yan-Fa Li Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Wed, 27 Mar 2002 23:26:07 -0800 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.9a |January 7, 2002) at 03/28/2002 12:44:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1324 Lines: 42 > I have a network testing app that would like to open > 100K outgoing sockets. I have modified my local range > in /proc/sys to allow 2048 - 65000 sockets to be used > for out going connections. > I start another client on System A and tell it to connect > to 10.10.14.197 port 443. This client is also told to open 50K > sockets. At ~12K sockets it fails. What fails? Is it the socket() call? What error does it fail with? For instance, is it failing with a ENOBUFS or ENOMEM? EAGAIN, ETIMEDOUT? What kind of socket: TCP or UDP? (TCP, I assume, but neednt be). Have you bumped up limits like /proc/sys/fs/inode_max, file-max? System wide, ulimit? > So here's my question, I'm a novice at this sort of thing so > I may have done something completely off the wall, but assuming > I'm going out a different network interface, why are all socket > allocations for outgoing connections appearing to come out of > the same pool ? > Logically speaking, shouldn't it be possible to use the same > socket number for an outgoing socket going out a totally > different network interface and thus get another completely > unused socket range ? Am I just missing a /proc/sys configuration > switch ? Port space is unique for a protocol (i.e.: TCP or UDP) across a host, independent of interfaces. thanks, Nivedita From owner-netdev@oss.sgi.com Thu Mar 28 00:32:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2S8WF832092 for netdev-outgoing; Thu, 28 Mar 2002 00:32:15 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2S8WCq32089 for ; Thu, 28 Mar 2002 00:32:12 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id DAA104080; Thu, 28 Mar 2002 03:31:11 -0500 Received: from d03nm035.boulder.ibm.com (d03nm035.boulder.ibm.com [9.17.194.35]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2S8YVp70806; Thu, 28 Mar 2002 01:34:31 -0700 From: "Nivedita Singhvi" Importance: Normal Sensitivity: Subject: Re: Opening more than 65000 sockets To: yanfali@yahoo.com Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Thu, 28 Mar 2002 00:31:29 -0800 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.9a |January 7, 2002) at 03/28/2002 01:34:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 632 Lines: 22 >> I start another client on System A and tell it to connect >> to 10.10.14.197 port 443. This client is also told to >> open 50K sockets. At ~12K sockets it fails. > What fails? Is it the socket() call? What error does it fail > with? For instance, is it failing with a ENOBUFS or > ENOMEM? EAGAIN, ETIMEDOUT? What kind of socket: TCP or UDP? > (TCP, I assume, but neednt be). Have you bumped up limits > like /proc/sys/fs/inode_max, file-max? System wide, ulimit? You dont mention which kernel version youre using, but on a recent kernel you wont need inode-max, think that went away sometime in 2.4. thanks, Nivedita From owner-netdev@oss.sgi.com Thu Mar 28 04:52:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SCqgd09109 for netdev-outgoing; Thu, 28 Mar 2002 04:52:42 -0800 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2SCqdq09106 for ; Thu, 28 Mar 2002 04:52:40 -0800 Received: from brinquendo.conectiva.com.br (1-098.ctame701-2.telepar.net.br [200.181.138.98]) by netbank.com.br (Postfix) with ESMTP id 7839746868; Thu, 28 Mar 2002 09:53:40 -0300 (EST) Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 49F6D1966C; Thu, 28 Mar 2002 10:05:06 -0300 (BRT) Date: Thu, 28 Mar 2002 10:05:06 -0300 From: Arnaldo Carvalho de Melo To: Yan-Fa Li Cc: netdev@oss.sgi.com Subject: Re: Opening more than 65000 sockets Message-ID: <20020328130505.GB1064@conectiva.com.br> References: <20020328013117.55739.qmail@web13003.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020328013117.55739.qmail@web13003.mail.yahoo.com> User-Agent: Mutt/1.3.28i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 202 Lines: 7 Em Wed, Mar 27, 2002 at 05:31:17PM -0800, Yan-Fa Li escreveu: > sockets. At ~12K sockets it fails. 2.4? Can you try with 2.5.x, where x > 4 and post how many sockets you manage to create? - Arnaldo From owner-netdev@oss.sgi.com Thu Mar 28 16:28:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2T0Smk27065 for netdev-outgoing; Thu, 28 Mar 2002 16:28:48 -0800 Received: from web13008.mail.yahoo.com (web13008.mail.yahoo.com [216.136.174.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2T0Sjq27062 for ; Thu, 28 Mar 2002 16:28:45 -0800 Message-ID: <20020329003109.68224.qmail@web13008.mail.yahoo.com> Received: from [65.209.235.11] by web13008.mail.yahoo.com via HTTP; Thu, 28 Mar 2002 16:31:09 PST Date: Thu, 28 Mar 2002 16:31:09 -0800 (PST) From: Yan-Fa Li Subject: Re: Opening more than 65000 sockets To: netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 615 Lines: 24 It fails in the connect() call. I get EAGAIN messages. They are TCP socekts. I have my file-max at 1 Million files, and ulimit the same. > > Port space is unique for a protocol (i.e.: TCP or UDP) > across a host, independent of interfaces. > If this is true then it looks like I'll have to get more hosts. However logically speaking I would have thought each LAN interface would have it's own TCP port space. Thanks for the advice. > > thanks, > Nivedita > > __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From owner-netdev@oss.sgi.com Thu Mar 28 18:05:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2T25Ys28573 for netdev-outgoing; Thu, 28 Mar 2002 18:05:34 -0800 Received: from web13001.mail.yahoo.com (web13001.mail.yahoo.com [216.136.174.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2T25Uq28570 for ; Thu, 28 Mar 2002 18:05:30 -0800 Message-ID: <20020329020754.2221.qmail@web13001.mail.yahoo.com> Received: from [65.209.235.11] by web13001.mail.yahoo.com via HTTP; Thu, 28 Mar 2002 18:07:54 PST Date: Thu, 28 Mar 2002 18:07:54 -0800 (PST) From: Yan-Fa Li Subject: Re: Opening more than 65000 sockets To: Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com In-Reply-To: <20020328130505.GB1064@conectiva.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 767 Lines: 29 Hi, yes I just tried 2.5, it's not a memory problem. Fails at the connect() consistently at the same place. It appears that TCP source ports are unique across the whole system not per interface. I guess my question is, is this the correct behavior ? My first guess would have been no, but obviously empirically I'm wrong. Thanks Yan --- Arnaldo Carvalho de Melo wrote: > Em Wed, Mar 27, 2002 at 05:31:17PM -0800, Yan-Fa Li escreveu: > > sockets. At ~12K sockets it fails. > > 2.4? Can you try with 2.5.x, where x > 4 and post how many sockets > you > manage to create? > > - Arnaldo __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From owner-netdev@oss.sgi.com Fri Mar 29 09:29:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2THTGR19950 for netdev-outgoing; Fri, 29 Mar 2002 09:29:16 -0800 Received: from grok.yi.org (ip68-3-107-226.ph.ph.cox.net [68.3.107.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2THT4q19947 for ; Fri, 29 Mar 2002 09:29:09 -0800 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g2THVQL01724; Fri, 29 Mar 2002 10:31:26 -0700 Message-ID: <3CA4A4EE.3030706@candelatech.com> Date: Fri, 29 Mar 2002 10:31:26 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Yan-Fa Li CC: netdev@oss.sgi.com Subject: Re: Opening more than 65000 sockets References: <20020329003109.68224.qmail@web13008.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by grok.yi.org id g2THVQL01724 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2THT9q19948 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1057 Lines: 47 Yan-Fa Li wrote: > It fails in the connect() call. I get EAGAIN messages. > They are TCP socekts. I have my file-max at 1 Million > files, and ulimit the same. > >>Port space is unique for a protocol (i.e.: TCP or UDP) >>across a host, independent of interfaces. >> That really looks like a bug or mis-feature to me. Why would we want this limitation? What would be the problems with fixing it to be per-local-interface? >> > > If this is true then it looks like I'll have to get > more hosts. However logically speaking I would have > thought each LAN interface would have it's own TCP port > space. Thanks for the advice. > > >>thanks, >>Nivedita >> >> >> > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Movies - coverage of the 74th Academy Awards® > http://movies.yahoo.com/ > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Fri Mar 29 10:06:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TI6Ax20963 for netdev-outgoing; Fri, 29 Mar 2002 10:06:10 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TI66q20959 for ; Fri, 29 Mar 2002 10:06:06 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA85888; Fri, 29 Mar 2002 13:04:56 -0500 Received: from w-sridhar2.des.beaverton.ibm.com (w-sridhar2.des.beaverton.ibm.com [9.47.18.20]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2TI8K030978; Fri, 29 Mar 2002 11:08:20 -0700 Date: Fri, 29 Mar 2002 11:08:18 -0800 (PST) From: Sridhar Samudrala X-Sender: sridhar@w-sridhar2.des.beaverton.ibm.com To: Ben Greear cc: Yan-Fa Li , netdev@oss.sgi.com Subject: Re: Opening more than 65000 sockets In-Reply-To: <3CA4A4EE.3030706@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 739 Lines: 27 On Fri, 29 Mar 2002, Ben Greear wrote: > > > Yan-Fa Li wrote: > > > It fails in the connect() call. I get EAGAIN messages. > > They are TCP socekts. I have my file-max at 1 Million > > files, and ulimit the same. > > > >>Port space is unique for a protocol (i.e.: TCP or UDP) > >>across a host, independent of interfaces. > >> > > > That really looks like a bug or mis-feature to me. Why > would we want this limitation? What would be the problems > with fixing it to be per-local-interface? you can use the socket option SO_REUSEADDR to bind the same port to multiple sockets, as long as each bind specifies a different local IP address. In this way the port space becomes unique for each local ip address. Thanks Sridhar From owner-netdev@oss.sgi.com Fri Mar 29 11:43:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TJhsf23216 for netdev-outgoing; Fri, 29 Mar 2002 11:43:54 -0800 Received: from web13007.mail.yahoo.com (web13007.mail.yahoo.com [216.136.174.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TJhkq23212 for ; Fri, 29 Mar 2002 11:43:46 -0800 Message-ID: <20020329194608.32090.qmail@web13007.mail.yahoo.com> Received: from [65.209.235.11] by web13007.mail.yahoo.com via HTTP; Fri, 29 Mar 2002 11:46:08 PST Date: Fri, 29 Mar 2002 11:46:08 -0800 (PST) From: Yan-Fa Li Subject: Re: Opening more than 65000 sockets To: Sridhar Samudrala , Ben Greear Cc: Yan-Fa Li , netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4653 Lines: 141 Thanks for the tip. I tried it out and it doesn't appear to work. It actually fails with a different return code EINVAL (22). Which isn't even a listed return code on the connect() man page :( Anybody else got any more ideas I can try ? Here's what I used: k=tcp and on=1 setsockopt(*opensock,k->p_proto,SO_REUSEADDR,&on,sizeof(on)); Is this the wrong syntax ? Anyway what I really want seems to be SO_REUSEPORT, and looking at the source code I see this in /usr/src/linux/include/asm/socket.h: #define SO_BSDCOMPAT 14 /* To add :#define SO_REUSEPORT 15 */ #define SO_PASSCRED 16 I guess we don't support this feature by design :( Any clues on if the support is in the kernel but not turned on ? Or is this something for 2.5 only ? Thanks Yan p.s. this is 2.4.19-pre3aa2 with /dev/epoll-31 patches. --- Sridhar Samudrala wrote: > On Fri, 29 Mar 2002, Ben Greear wrote: > > > > > > > Yan-Fa Li wrote: > > > > > It fails in the connect() call. I get EAGAIN messages. > > > They are TCP socekts. I have my file-max at 1 Million > > > files, and ulimit the same. > > > > > >>Port space is unique for a protocol (i.e.: TCP or UDP) > > >>across a host, independent of interfaces. > > >> > > > > > > That really looks like a bug or mis-feature to me. Why > > would we want this limitation? What would be the problems > > with fixing it to be per-local-interface? > > you can use the socket option SO_REUSEADDR to bind the same port to > multiple sockets, as long as each bind specifies a different localFrom owner-netdev@oss.sgi.com Fri Mar 29 12:49:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TJhsf23216 for netdev-outgoing; Fri, 29 Mar 2002 11:43:54 -0800 Received: from web13007.mail.yahoo.com (web13007.mail.yahoo.com [216.136.174.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TJhkq23212 for ; Fri, 29 Mar 2002 11:43:46 -0800 Message-ID: <20020329194608.32090.qmail@web13007.mail.yahoo.com> Received: from [65.209.235.11] by web13007.mail.yahoo.com via HTTP; Fri, 29 Mar 2002 11:46:08 PST Date: Fri, 29 Mar 2002 11:46:08 -0800 (PST) From: Yan-Fa Li Subject: Re: Opening more than 65000 sockets To: Sridhar Samudrala , Ben Greear Cc: Yan-Fa Li , netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Thanks for the tip. I tried it out and it doesn't appear to work. It actually fails with a different return code EINVAL (22). Which isn't even a listed return code on the connect() man page :( Anybody else got any more ideas I can try ? Here's what I used: k=tcp and on=1 setsockopt(*opensock,k->p_proto,SO_REUSEADDR,&on,sizeof(on)); Is this the wrong syntax ? Anyway what I really want seems to be SO_REUSEPORT, and looking at the source code I see this in /usr/src/linux/include/asm/socket.h: #define SO_BSDCOMPAT 14 /* To add :#define SO_REUSEPORT 15 */ #define SO_PASSCRED 16 I guess we don't support this feature by design :( Any clues on if the support is in the kernel but not turned on ? Or is this something for 2.5 only ? Thanks Yan p.s. this is 2.4.19-pre3aa2 with /dev/epoll-31 patches. --- Sridhar Samudrala wrote: > On Fri, 29 Mar 2002, Ben Greear wrote: > > > > > > > Yan-Fa Li wrote: > > > > > It fails in the connect() call. I get EAGAIN messages. > > > They are TCP socekts. I have my file-max at 1 Million > > > files, and ulimit the same. > > > > > >>Port space is unique for a protocol (i.e.: TCP or UDP) > > >>across a host, independent of interfaces. > > >> > > > > > > That really looks like a bug or mis-feature to me. Why > > would we want this limitation? What would be the problems > > with fixing it to be per-local-interface? > > you can use the socket option SO_REUSEADDR to bind the same port to > multiple sockets, as long as each bind specifies a different local IP > address. > In this way the port space becomes unique for each local ip address. > > Thanks > Sridhar > __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ From owner-netdev@oss.sgi.com Fri Mar 29 13:26:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TLQkn00788 for netdev-outgoing; Fri, 29 Mar 2002 13:26:46 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TLQX200785 for ; Fri, 29 Mar 2002 13:26:33 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA02680 for ; Fri, 29 Mar 2002 12:25:26 -0800 (PST) mail_from (sri@us.ibm.com) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA83896; Fri, 29 Mar 2002 15:20:32 -0500 Received: from w-sridhar2.des.beaverton.ibm.com (w-sridhar2.des.beaverton.ibm.com [9.47.18.20]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2TKNu0130408; Fri, 29 Mar 2002 13:23:56 -0700 Date: Fri, 29 Mar 2002 13:23:50 -0800 (PST) From: Sridhar Samudrala X-Sender: sridhar@w-sridhar2.des.beaverton.ibm.com To: Yan-Fa Li cc: Sridhar Samudrala , Ben Greear , netdev@oss.sgi.com Subject: Re: Opening more than 65000 sockets In-Reply-To: <20020329194608.32090.qmail@web13007.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2627 Lines: 89 On Fri, 29 Mar 2002, Yan-Fa Li wrote: > Thanks for the tip. I tried it out and it doesn't > appear to work. It actually fails with a different > return code EINVAL (22). Which isn't even a listed > return code on the connect() man page :( looks like you are not doing a bind explicitly and allowing the connect() call to do the auto bind. If you want to create 2 sockets with 2 different ip addresses, but the same port, you should do explicit bind in your client specifying the ip address and the port. Also you need to set SO_REUSEADDR before the call to bind. > > Anybody else got any more ideas I can try ? > > Here's what I used: > > k=tcp and on=1 > > setsockopt(*opensock,k->p_proto,SO_REUSEADDR,&on,sizeof(on)); I am not sure what is k->p_proto. The 2nd argument should be SOL_SOCKET. > > Is this the wrong syntax ? > > Anyway what I really want seems to be SO_REUSEPORT, > and looking at the source code I see this in > /usr/src/linux/include/asm/socket.h: > > #define SO_BSDCOMPAT 14 > /* To add :#define SO_REUSEPORT 15 */ > #define SO_PASSCRED 16 > > I guess we don't support this feature by design :( > Any clues on if the support is in the kernel but not > turned on ? Or is this something for 2.5 only ? The names SO_REUSEPORT and SO_REUSEADDR are misleading. SO_REUSEPORT is used to allow completely duplicate bindings (4-tuple is same) and may not be supported on all the OSes. I think SO_REUSEADDR should work in your case. > > Thanks > > Yan > > p.s. this is 2.4.19-pre3aa2 with /dev/epoll-31 patches. > > --- Sridhar Samudrala wrote: > > On Fri, 29 Mar 2002, Ben Greear wrote: > > > > > > > > > > > Yan-Fa Li wrote: > > > > > > > It fails in the connect() call. I get EAGAIN messages. > > > > They are TCP socekts. I have my file-max at 1 Million > > > > files, and ulimit the same. > > > > > > > >>Port space is unique for a protocol (i.e.: TCP or UDP) > > > >>across a host, independent of interfaces. > > > >> > > > > > > > > > That really looks like a bug or mis-feature to me. Why > > > would we want this limitation? What would be the problems > > > with fixing it to be per-local-interface? > > > > you can use the socket option SO_REUSEADDR to bind the same port to > > multiple sockets, as long as each bind specifies a different local IP > > address. > > In this way the port space becomes unique for each local ip address. > > > > Thanks > > Sridhar > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Greetings - send holiday greetings for Easter, Passover > http://greetings.yahoo.com/ > From owner-netdev@oss.sgi.com Fri Mar 29 13:28:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TLS1500832 for netdev-outgoing; Fri, 29 Mar 2002 13:28:01 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TLRv200829 for ; Fri, 29 Mar 2002 13:27:57 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA134714; Fri, 29 Mar 2002 15:24:29 -0500 Received: from d03nm035.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2TKRqF122292; Fri, 29 Mar 2002 13:27:52 -0700 From: "Nivedita Singhvi" Importance: Normal Sensitivity: Subject: Re: Opening more than 65000 sockets To: Yan-Fa Li Cc: sri@linux.ibm.com.sgi.com, Ben Greear , Yan-Fa Li , netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Fri, 29 Mar 2002 12:27:50 -0800 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.9a |January 7, 2002) at 03/29/2002 01:27:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 627 Lines: 28 Are you doing a bind() to the unique local address you wanted? Are you doing the setsockopt() prior to that? bind() returns an EINVAL when the port is being used, if you havent actually done a REUSEADDR, which is what you need in this case.. thanks, Nivedita > Thanks for the tip. I tried it out and it doesn't > appear to work. It actually fails with a different > return code EINVAL (22). Which isn't even a listed > return code on the connect() man page :( > Anybody else got any more ideas I can try ? > Here's what I used: > k=tcp and on=1 > setsockopt(*opensock,k->p_proto,SO_REUSEADDR,&on, > sizeof(on)); From owner-netdev@oss.sgi.com Fri Mar 29 14:35:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TMZKg00870 for netdev-outgoing; Fri, 29 Mar 2002 14:35:20 -0800 Received: from web13003.mail.yahoo.com (web13003.mail.yahoo.com [216.136.174.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TMZAv00866 for ; Fri, 29 Mar 2002 14:35:10 -0800 Message-ID: <20020329212827.4412.qmail@web13003.mail.yahoo.com> Received: from [65.209.235.11] by web13003.mail.yahoo.com via HTTP; Fri, 29 Mar 2002 13:28:27 PST Date: Fri, 29 Mar 2002 13:28:27 -0800 (PST) From: Yan-Fa Li Subject: Re: Opening more than 65000 sockets To: Sridhar Samudrala Cc: netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2565 Lines: 89 Thanks again. Ok I tried your suggestion but that didn't work either. Here's the offending code fragment, pardon the fugly coding: addr.sin_family = AF_INET; addr.sin_port = 0; he=gethostbyname(localint); addr.sin_addr.s_addr = ((unsigned long*) (he->h_addr_list[0]))[0]; setsockopt(*opensock,k->p_proto,SO_REUSEADDR,&on,sizeof(on)); bind(*opensock, (struct sockaddr *)&addr,sizeof(addr)); if (connect(*opensock, (struct sockaddr *) & server, sizeof(server)) <0) { .... } Now, I get this error code on connect: EAGAIN (11) So that doesn't apear to work either. Am I still coding this wrong ? It fails at exactly the same number of sockets as all my previous tries. Y --- Sridhar Samudrala wrote: > On Fri, 29 Mar 2002, Yan-Fa Li wrote: > > > Thanks for the tip. I tried it out and it doesn't > > appear to work. It actually fails with a different > > return code EINVAL (22). Which isn't even a listed > > return code on the connect() man page :( > > looks like you are not doing a bind explicitly and allowing the > connect() > call to do the auto bind. > If you want to create 2 sockets with 2 different ip addresses, but > the same > port, you should do explicit bind in your client specifying the ip > address > and the port. > > Also you need to set SO_REUSEADDR before the call to bind. > > > > > Anybody else got any more ideas I can try ? > > > > Here's what I used: > > > > k=tcp and on=1 > > > > setsockopt(*opensock,k->p_proto,SO_REUSEADDR,&on,sizeof(on)); > > I am not sure what is k->p_proto. The 2nd argument should be > SOL_SOCKET. > > > > > Is this the wrong syntax ? > > > > Anyway what I really want seems to be SO_REUSEPORT, > > and looking at the source code I see this in > > /usr/src/linux/include/asm/socket.h: > > > > #define SO_BSDCOMPAT 14 > > /* To add :#define SO_REUSEPORT 15 */ > > #define SO_PASSCRED 16 > > > > I guess we don't support this feature by design :( > > Any clues on if the support is in the kernel but not > > turned on ? Or is this something for 2.5 only ? > > The names SO_REUSEPORT and SO_REUSEADDR are misleading. SO_REUSEPORT > is used > to allow completely duplicate bindings (4-tuple is same) and may not > be > supported on all the OSes. > > I think SO_REUSEADDR should work in your case. > > > > Thanks > > > > Yan > > > > p.s. this is 2.4.19-pre3aa2 with /dev/epoll-31 patches. > > __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ From owner-netdev@oss.sgi.com Fri Mar 29 14:59:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TMxN201522 for netdev-outgoing; Fri, 29 Mar 2002 14:59:23 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TMx8v01518 for ; Fri, 29 Mar 2002 14:59:09 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA18424; Fri, 29 Mar 2002 16:55:41 -0500 Received: from d03nm035.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2TLx5q100488; Fri, 29 Mar 2002 14:59:05 -0700 From: "Nivedita Singhvi" Importance: Normal Sensitivity: Subject: Re: Opening more than 65000 sockets To: Yan-Fa Li Cc: sri@linux.ibm.com.sgi.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Fri, 29 Mar 2002 13:59:02 -0800 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.9a |January 7, 2002) at 03/29/2002 02:59:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3450 Lines: 127 Er, thats not exactly how it works. The problem is youre not specifying a port to bind to, which means the kernel is going to look for a free port. (in your case, there isnt any, and bind() returns an EINVAL). The SO_REUSEADDR option allows you to reuse a particular port, its not useful when you have wildcarded the port. (the kernel cant arbitrarily pick a port to reuse). So if you pick a particular port - all your connections will use the same port - probably what you want is to do this in a loop and specifically assign unique ports and reuse them .. You might want to error check after each call to correctly identify when youre getting an error. :) Hope that helps.. thanks, Nivedita Yan-Fa Li @oss.sgi.com on 03/29/2002 01:28:27 PM Sent by: owner-netdev@oss.sgi.com To: sri@linux.ibm.com cc: netdev@oss.sgi.com Subject: Re: Opening more than 65000 sockets Thanks again. Ok I tried your suggestion but that didn't work either. Here's the offending code fragment, pardon the fugly coding: addr.sin_family = AF_INET; addr.sin_port = 0; he=gethostbyname(localint); addr.sin_addr.s_addr = ((unsigned long*) (he->h_addr_list[0]))[0]; setsockopt(*opensock,k->p_proto,SO_REUSEADDR,&on,sizeof(on)); bind(*opensock, (struct sockaddr *)&addr,sizeof(addr)); if (connect(*opensock, (struct sockaddr *) & server, sizeof(server)) <0) { .... } Now, I get this error code on connect: EAGAIN (11) So that doesn't apear to work either. Am I still coding this wrong ? It fails at exactly the same number of sockets as all my previous tries. Y --- Sridhar Samudrala wrote: > On Fri, 29 Mar 2002, Yan-Fa Li wrote: > > > Thanks for the tip. I tried it out and it doesn't > > appear to work. It actually fails with a different > > return code EINVAL (22). Which isn't even a listed > > return code on the connect() man page :( > > looks like you are not doing a bind explicitly and allowing the > connect() > call to do the auto bind. > If you want to create 2 sockets with 2 different ip addresses, but > the same > port, you should do explicit bind in your client specifying the ip > address > and the port. > > Also you need to set SO_REUSEADDR before the call to bind. > > > > > Anybody else got any more ideas I can try ? > > > > Here's what I used: > > > > k=tcp and on=1 > > > > setsockopt(*opensock,k->p_proto,SO_REUSEADDR,&on,sizeof(on)); > > I am not sure what is k->p_proto. The 2nd argument should be > SOL_SOCKET. > > > > > Is this the wrong syntax ? > > > > Anyway what I really want seems to be SO_REUSEPORT, > > and looking at the source code I see this in > > /usr/src/linux/include/asm/socket.h: > > > > #define SO_BSDCOMPAT 14 > > /* To add :#define SO_REUSEPORT 15 */ > > #define SO_PASSCRED 16 > > > > I guess we don't support this feature by design :( > > Any clues on if the support is in the kernel but not > > turned on ? Or is this something for 2.5 only ? > > The names SO_REUSEPORT and SO_REUSEADDR are misleading. SO_REUSEPORT > is used > to allow completely duplicate bindings (4-tuple is same) and may not > be > supported on all the OSes. > > I think SO_REUSEADDR should work in your case. > > > > Thanks > > > > Yan > > > > p.s. this is 2.4.19-pre3aa2 with /dev/epoll-31 patches. > > __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ From owner-netdev@oss.sgi.com Fri Mar 29 15:27:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TNReO03021 for netdev-outgoing; Fri, 29 Mar 2002 15:27:40 -0800 Received: from web13002.mail.yahoo.com (web13002.mail.yahoo.com [216.136.174.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TNRYv03018 for ; Fri, 29 Mar 2002 15:27:34 -0800 Message-ID: <20020329232656.14100.qmail@web13002.mail.yahoo.com> Received: from [65.209.235.11] by web13002.mail.yahoo.com via HTTP; Fri, 29 Mar 2002 15:26:56 PST Date: Fri, 29 Mar 2002 15:26:56 -0800 (PST) From: Yan-Fa Li Subject: Re: Opening more than 65000 sockets To: Nivedita Singhvi Cc: netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1700 Lines: 47 Thank you for the insight! I re-coded it with more error checking, my bad, and caught that I was using setsockopt() incorrectly, wrong level, and then made the program specify ports to bind to and now everything seems to work great! 100K outgoing ports opened successfully. Awesome! Here's design question, so I have a lot of timewait sockets on exiting and I've set my fin_timeout to 5 seconds and they seem to disappear eventually (within a minute or so). I noticed I can set SO_LINGER and make the client send a RST and get out of this state faster, allowing me to restart the client sooner. I realize this is valid TCP behavior but is it typical network client behavior say from a browser versus doing the correct handshake ? Y --- Nivedita Singhvi wrote: > > Er, thats not exactly how it works. > > The problem is youre not specifying a port to bind to, which > means the kernel is going to look for a free port. (in your case, > there isnt any, and bind() returns an EINVAL). > > The SO_REUSEADDR option allows you to reuse a particular > port, its not useful when you have wildcarded the port. (the kernel > cant arbitrarily pick a port to reuse). > > So if you pick a particular port - all your connections will use the > same port - probably what you want is to do this in a loop and > specifically assign unique ports and reuse them .. > > You might want to error check after each call to correctly identify > when youre getting an error. :) > > Hope that helps.. > > thanks, > Nivedita > > __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ From owner-netdev@oss.sgi.com Sat Mar 30 19:36:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2V3aO022063 for netdev-outgoing; Sat, 30 Mar 2002 19:36:24 -0800 Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2V3aKv22060 for ; Sat, 30 Mar 2002 19:36:20 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA24848; Sat, 30 Mar 2002 22:35:36 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g2V3Ub608663; Sat, 30 Mar 2002 22:30:38 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 30 Mar 2002 22:30:37 -0500 (EST) From: jamal To: Stefan Rompf cc: , Subject: Re: Patch: Device operative state notification against 2.5.7 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 980 Lines: 25 Hi, in the future can you please just post to netdev on networking related issues? I responded to lk, but feel free to remove it from the list. -I am not sure the idea of using a kernel thread is the best. Maybe move the checks to both the tx or rx softirqs instead of its own scheduling. -In particular, it would be a better idea not to just go walking all the devices; only walk devices that have raised an netif_carrier_. -A shared devices bitmask across SMP should be enough (i.e no need for per-CPU state) -Another thing might be to double check that the condition that raised the state change is still valid example - in between the moment you say a link is down due to some bad hardware fault to the moment some device timer recovers it; -Also IFF_RUNNING seems to have inconsistent semantics in a lot of drivers. It should really stand for "operational status" whereas IFF_UP should stand for "admin status" -- anyone wanna shed historical wisdom here? cheers, jamal From owner-netdev@oss.sgi.com Sun Mar 31 08:27:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2VGR9X04440 for netdev-outgoing; Sun, 31 Mar 2002 08:27:09 -0800 Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2VGQrv04433 for ; Sun, 31 Mar 2002 08:26:53 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id LAA07501; Sun, 31 Mar 2002 11:26:13 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g2VGLGp10036; Sun, 31 Mar 2002 11:21:16 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 31 Mar 2002 11:21:16 -0500 (EST) From: jamal To: Stefan Rompf cc: Subject: Re: Patch: Device operative state notification against 2.5.7 In-Reply-To: <3CA6E3BF.8815AA4F@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 5947 Lines: 135 On Sun, 31 Mar 2002, Stefan Rompf wrote: > Hi Jamal, > > > in the future can you please just post to netdev on networking > > related issues? I responded to lk, but feel free to remove it > > from the list. > > ok. Do all netdev people already know the patch or shall I repost it to > this list? For the uninitiated, here is where i saw it: http://marc.theaimsgroup.com/?l=linux-net&m=101751062827998&w=1 (sorry, i am not subscribed to lk) > > > -I am not sure the idea of using a kernel thread is the best. Maybe > > move the checks to both the tx or rx softirqs instead of its own scheduling. > > -In particular, it would be a better idea not to just go walking all the > > devices; only walk devices that have raised an netif_carrier_. > > Is it possible to send (netlink) messages from a softirq? Why not? > Anyway, in the > tx/rx softirqs the check would be executed for nearly every packet, so > the tradeoff of having a kernel thread that polls the devices on request > (so may be never as long as the network is fine) seems better to me, > even if it has to walk through the complete list. Moving it to softirq gives it more privilege; however, you are right, the tx/rx softirqs might not be the best place (i thought people will scream at you if you went ahead and created a sofirq just for this). In any case, this is a lesser concern for now, a few ms later is no biggie... In regards to walking the whole dev list: There is no point in polling when there is no work to be done (and therefore no need for you to walk all the devices which have not shown interest). A simple "registration" by devices raising or lowering carrier would be the best way to do it (via netif_carrier_on/ff). The first device on the list also wakes up the thread (or as you do right now always wakes it up). Keep rescheduling the thread until there are no more devices left (no need for the timer) -- killing the thread might not be a bad idea either since you would expect this not to happen that often. > > > -A shared devices bitmask across SMP should be enough (i.e no need for > > per-CPU state) > > Neither dev->flags nor dev->state are per-CPU. Am I missing something? I meant the structure that keeps track of changed carrier state .. Example the simple linked list i mentioned above; > > -Another thing might be to double check that the condition that raised > > the state change is still valid example - > > in between the moment you say a link is down due to some bad hardware > > fault to the moment some device timer recovers it; > > The patch does that. After the thread wakes up, it iterates over the > device list and sends only messages if it sees differences between > IFF_RUNNING and LINK_STATE_NO_CARRIER. > I think you need to watch serialization issues with netif_carrier_on/off between the driver and the top layer. The difference between IFF_RUNNING and LINK_STATE_NO_CARRIER, IMO, is insufficient check. This is because the semantics of IFF_RUNNING are not well defined. Currently from scanning drivers i see IFF_RUNNING following LINK_STATE_NO_CARRIER always i.e IFF_RUNNING is set when LINK_STATE_NO_CARRIER is deasserted and vice-versa. Note this is not always the case and it also does not say that we went from operational down to up or vice-versa or whether we went on->off->on i.e looking at those two flags alone is ambigous. Note, you want to report both transitions and you also want to make sure its not just simple noise. > > -Also IFF_RUNNING seems to have inconsistent semantics in a lot of > > drivers. It should really stand for "operational status" whereas > > IFF_UP should stand for "admin status" -- anyone wanna shed historical > > wisdom here? > > Ultimately, that's what I want IFF_RUNNING to become in linux. > > There are 14 files left below linux/drivers that still play with > IFF_RUNNING instead of using the netif_carrier_o* functions. I'm willing > to supply patches for them as they are broken anyway, but I won't be > able to do more than a test if the modifications compile. > If we were to follow the BSD or CISCOish view of the world, then removing a cable or death of allocated virtual circuit/tunnel would mean !IFF_RUNNING. If i was to draw a truth table it would look like: NO_CARRIER | IFF_RUNNING | meaning -----------|-------------|------------------------------------ !set | !set | There is carrier, but no cable | | no sense for ethernet; but may be useful | | for PPP (for example line protocol is not up) -----------|-------------|---------------------------------------- !set | set | operational up | | | | -----------|-------------|-------------------------------------- set | !set | operational down | | | | -----------|-------------|-------------------------------------- set | set | carrier off, cable on; not sure what this | | means (may make sense for host scope) | | -----------|-------------|-------------------------------------- You still need to maintain state to catch the on->off->on. For example, no point in reporting such state transition via netlink -- but you could call that an optimization. TB above is a little different from what you have in your code (essentially you also add to the noise by mucking with IFF_RUNNING) which in itself is philosophical in nature: - Is it correct to get rid of the driver having a say in IFF_RUNNING? For example is it correct that the core code sets IFF_RUNNING on the device? Think of either a bonding, VLANs or extreme case where PPP circuit is up for one protocol but not for another. We need to disambiguate operational and admin status very clearly. Eg should ifconfing-ing up a device mean it is also IFF_RUNNING (this is what ifconfig does i think) cheers, jamal From owner-netdev@oss.sgi.com Sun Mar 31 11:14:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2VJEc505817 for netdev-outgoing; Sun, 31 Mar 2002 11:14:38 -0800 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2VJEUv05814 for ; Sun, 31 Mar 2002 11:14:31 -0800 Received: (qmail 24721 invoked by uid 2001); 31 Mar 2002 19:13:46 -0000 Date: Sun, 31 Mar 2002 21:13:46 +0200 From: Petr Baudis To: xs26-dev@xs26.net Cc: Petr Baudis , Pekka Savola , Jan Oravec , netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: addrconf.c - possible bug Message-ID: <20020331191346.GI1954@pasky.ji.cz> Reply-To: xs26-dev@xs26.net References: <20020323165921.GC1954@pasky.ji.cz> <20020323184451.GD1954@pasky.ji.cz> <20020324195737.GM1954@pasky.ji.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020324195737.GM1954@pasky.ji.cz> User-Agent: Mutt/1.5.0i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2641 Lines: 52 Dear diary, on Sun, Mar 24, 2002 at 08:57:37PM CET, I got a letter, where Petr Baudis told me, that... > Dear diary, on Sat, Mar 23, 2002 at 07:44:51PM CET, I got a letter, > where Petr Baudis told me, that... > > I started the tcpdump there, and we'll see. However, by looking into code, we > > found no possibility how would zebra want to mess with loopback. > > > > Also, we discovered that just taking down and back up any ONE interface will > > fix this for ALL other interfaces as well. > > It failed again and tcpdump still runs happily. Again, taking one of the > interfaces down and back up (maybe it's worth mentioning that the machine acts > as XS26 PoP, thus it have about 270 interfaces just now up) fixed the problem > and the machine started to reply to neighbor solicitations again. Just as a reminder and for a record, quite nice record of conversation of two such broken linuxes. 20:43:48.596927 fe80::3e8c:1d09 > fe80::3e18:401b: OSPFv3-dd 28: rtrid secret.host backbone V6/E/R I/M/MS mtu 1480 S 3CA76B2D [hlim 1] 20:43:51.433416 fe80::3e18:401b > fe80::3e8c:1d09: OSPFv3-ls_upd 1256: rtrid rover.dkm.cz backbone 20:43:51.456066 fe80::3e8c:1d09 > fe80::3e18:401b: icmp6: redirect fe80::3e8c:1d09 to fe80::3e8c:1d09 20:43:51.456147 fe80::3e18:401b > fe80::3e8c:1d09: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b 20:43:51.456176 fe80::3e8c:1d09 > fe80::3e18:401b: icmp6: redirect fe80::3e8c:1d09 to fe80::3e8c:1d09 20:43:51.456758 fe80::3e18:401b > fe80::3e8c:1d09: OSPFv3-ls_upd 1256: rtrid rover.dkm.cz backbone 20:43:51.456840 fe80::3e18:401b > fe80::3e8c:1d09: OSPFv3-ls_upd 1256: rtrid rover.dkm.cz backbone 20:43:51.478662 fe80::3e8c:1d09 > fe80::3e18:401b: icmp6: redirect fe80::3e8c:1d09 to fe80::3e8c:1d09 (as a result?) 20:46:54.618539 fe80::3e8c:1d09 > fe80::3e8c:1d09: icmp6: time exceeded in-transit for fe80::3e18:401b 20:46:54.618588 fe80::3e8c:1d09 > fe80::3e8c:1d09: icmp6: time exceeded in-transit for fe80::3e18:401b [hlim 1] ..a lot of that.. It looks they're not going to talk together :). And another excellent example of the problem: 20:47:58.981124 fe80::2a0:c9ff:fea8:c91c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b 20:47:58.981175 fe80::3e18:401b > fe80::2a0:c9ff:fea8:c91c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b Kind regards, -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI hacker . Teamwork is essential -- it allows you to blame someone else. . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/