Displaying 7 results from an estimated 7 matches for "iff_loopback".
Did you mean:
f_loopback
2005 Jan 06
0
skip unconnected interfaces
...sysfs_class_net, de->d_name);
- if (i < 0 || i >= PATH_MAX-1)
+
+ if (ulong_from_sys_device_file(sysfs_class_net, de->d_name, "flags", &flags) < 0)
continue;
- t[i] = '\0';
- fd = open(t, O_RDONLY);
- if (fd < 0) {
- perror(t);
+ if ((flags & IFF_LOOPBACK)
+ || !(flags & (IFF_BROADCAST|IFF_POINTOPOINT)))
continue;
- }
- i = read(fd, &p, sizeof(p) - 1);
- close(fd);
- if (i < 0) {
- perror(t);
+
+ if ( !(dev = add_device(de->d_name)) )
continue;
- }
- p[i] = '\0';
- flags = strtoul(p, NULL, 0);
- /* Heuri...
2003 May 26
0
ip_input.c
...----------------------
/* 127/8 must not appear on wire - RFC1122 */
if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET ||
(ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) {
if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) == 0) {
ipstat.ips_badaddr++;
goto bad;
}
}
;-------------------------------------------
If we have such wonderful code inside freeBSD kernel, do we really
need to duplicate in default rc.firewall:
;-------------------------------------------...
2009 Apr 21
2
[Bridge] NIC unicast macs table manipulation by bridge
Using a Linux bridge I see that none of the interfaces is set to promiscuous
mode but on the other hand I don't see any dev_unicast_xxx calls in the
bridge code... for the case of one of the interfaces being a physical NIC
(e.g eth1), what's the magic that makes the NIC RX filtering be willing
to accept frames whos dest mac isn't the NIC "primary" unicast mac?
Also is there
2013 Apr 12
3
[Bug 814] rpfilter blocks broadcast packets
https://bugzilla.netfilter.org/show_bug.cgi?id=814
Florian Westphal <fw at strlen.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fw at strlen.de
--- Comment #1 from Florian Westphal <fw at strlen.de> 2013-04-12 10:24:14 CEST ---
(In reply
2014 Dec 17
20
[PATCH 00/10] Split UFO into v4 and v6 versions.
UFO support in the kernel applies to both IPv4 and IPv6 protocols
with the same device feature. However some devices may not be able
to support one of the offloads. For this we split the UFO offload
feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and
this series introduces NETIF_F_UFO6.
As a result of this work, we can now re-enable NETIF_F_UFO on
virtio_net devices and restore
2014 Dec 17
20
[PATCH 00/10] Split UFO into v4 and v6 versions.
UFO support in the kernel applies to both IPv4 and IPv6 protocols
with the same device feature. However some devices may not be able
to support one of the offloads. For this we split the UFO offload
feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and
this series introduces NETIF_F_UFO6.
As a result of this work, we can now re-enable NETIF_F_UFO on
virtio_net devices and restore
2003 May 22
0
[PATCH 2.5.69 1/3] remove ipconfig support from the kernel
...nit ic_open_devs(void)
-{
- struct ic_device *d, **last;
- struct net_device *dev;
- unsigned short oflags;
-
- last = &ic_first_dev;
- rtnl_shlock();
- for (dev = dev_base; dev; dev = dev->next) {
- if (user_dev_name[0] ? !strcmp(dev->name, user_dev_name) :
- (!(dev->flags & IFF_LOOPBACK) &&
- (dev->flags & (IFF_POINTOPOINT|IFF_BROADCAST)) &&
- strncmp(dev->name, "dummy", 5))) {
- int able = 0;
- if (dev->mtu >= 364)
- able |= IC_BOOTP;
- else
- printk(KERN_WARNING "DHCP/BOOTP: Ignoring device %s, MTU %d too sma...