search for: __constant_htons

...r size + VLAN header size. - add BRNF_NF_BRIDGE_PREROUTING mask, to make sure the iptables PREROUTING chain isn't traversed twice. The old mechanism isn't satisfactory when the bridge port is a VLAN tagged device. - add some code in vlan_dev.c::vlan_dev_hard_start_xmit(): skb->protocol = __constant_htons(ETH_P_8021Q); skb->mac.raw -= VLAN_HLEN; skb->nh.raw -= VLAN_HLEN; When the logical VLAN device adds its VLAN header to the packet, I think it should update the skb. The protocol then becomes VLAN, the Ethernet header pointer should be updated correctly. Also, the network header pointer shoul...

The __constant_htons and similar are defined in klibc version of netinet/in.h, but not in glibc counterpart. Include the same thing from <asm/byteorder.h>, which is available in both glibc and klibc. Perhaps __constant_htons should be dropped from the klibc version of netinet/in.h: it provides nothing that you c...

...route2/ip'' gcc ip.o ipaddress.o iproute.o iprule.o rtm_map.o iptunnel.o ipneigh.o iplink.o ipmaddr.o ipmonitor.o ipmroute.o ../lib/libnetlink.a ../lib/libutil.a -lresolv -L../lib -lnetlink -lutil -o ip iptunnel.o(.text+0x65a): In function `parse_args'': : undefined reference to `__constant_htons'' iptunnel.o(.text+0x678): In function `parse_args'': : undefined reference to `__constant_htons'' iptunnel.o(.text+0x75d): In function `parse_args'': : undefined reference to `__constant_htons'' iptunnel.o(.text+0x830): In function `parse_args'': : u...

...quot;ipconfig.h" #include "netdev.h" #include "packet.h" static int pkt_fd; +__u16 local_port = LOCAL_PORT; +__u16 remote_port = REMOTE_PORT; + int packet_open(void) { int fd, one = 1; @@ -83,8 +87,8 @@ .daddr = INADDR_BROADCAST, }, .udp = { - .source = __constant_htons(68), - .dest = __constant_htons(67), + .source = __constant_htons(LOCAL_PORT), + .dest = __constant_htons(REMOTE_PORT), .len = 0, .check = 0, }, @@ -108,6 +112,11 @@ }; int i, len = 0; + if (local_port != LOCAL_PORT) { + ipudp_hdrs.udp.source = htons(local_port); + ipudp_hdr...

...er >Cc: netdev@oss.sgi.com; vlan@wanfear.com; bridge >Subject: [VLAN] Re: [PATCH/RFC] Let {ip,arp}tables "see" bridged VLAN >tagged{I,AR}P packets > > >Bart De Schuymer wrote: >> - add some code in vlan_dev.c::vlan_dev_hard_start_xmit(): >> skb->protocol = __constant_htons(ETH_P_8021Q); >> skb->mac.raw -= VLAN_HLEN; >> skb->nh.raw -= VLAN_HLEN; > >I wonder if this is what was messing up the tcpdump packet capture >as well? Hi Ben and all others, Just to clarify for other who hasn't been a part of this discussion before. ---- 8<...

...f -urN ./orig/sch_esfq.c ./patched/sch_esfq.c --- ./orig/sch_esfq.c 2004-02-26 09:27:54.000000000 +0100 +++ ./patched/sch_esfq.c 2004-01-07 21:39:24.000000000 +0100 @@ -117,6 +117,7 @@ { u32 h, h2; u32 hs; + u32 nfm; switch (skb->protocol) { case __constant_htons(ETH_P_IP): @@ -124,6 +125,7 @@ struct iphdr *iph = skb->nh.iph; h = iph->daddr; hs = iph->saddr; + nfm = skb -> nfmark; h2 = hs^iph->protocol; if (!(iph->frag_off&htons(IP_MF|IP_OFFSE...

Hi If I have a HTB class with 128kbit, and I want to put "N" users in that class ( in order to share bandwidth fairly ) , which is better for me ? esfq (hash dst) or wrr ? I would attach esfq or wrr to HTB parent class. Also I''ve readed on Jim script that over WRR put a RED qdisc, but I don''t understand it. bests andres

Hi: Here are the patches I used for testing KVM with virtio-net using TSO. There are three patches for the tun device which are basically Rusty's patches with the mmap turned into copying (for correctness). Two patches are for the virtio-net frontend, one required to support receiving SG/TSO, and the other useful for testing SG per se. The other patch is to the KVM backend to make all this

Hi: Here are the patches I used for testing KVM with virtio-net using TSO. There are three patches for the tun device which are basically Rusty's patches with the mmap turned into copying (for correctness). Two patches are for the virtio-net frontend, one required to support receiving SG/TSO, and the other useful for testing SG per se. The other patch is to the KVM backend to make all this

1) Turn GSO on virtio net into an all-or-nothing (keep checksumming separate). Having multiple bits is a pain: if you can't support something you should handle it in software, which is still a performance win. 2) Make VIRTIO_NET_HDR_GSO_ECN a flag in the header, so it can apply to IPv6 or v4. 3) Rename VIRTIO_NET_F_NO_CSUM to VIRTIO_NET_F_CSUM (ie. means we do checksumming). 4)

1) Turn GSO on virtio net into an all-or-nothing (keep checksumming separate). Having multiple bits is a pain: if you can't support something you should handle it in software, which is still a performance win. 2) Make VIRTIO_NET_HDR_GSO_ECN a flag in the header, so it can apply to IPv6 or v4. 3) Rename VIRTIO_NET_F_NO_CSUM to VIRTIO_NET_F_CSUM (ie. means we do checksumming). 4)

Hi again, I was just looking around for ESFQ sources, and I see that the main site is down, and only has kernel 2.6.4 patches. Is ESFQ maintained? If so, where can I find patches for 2.6.10? Thanks, -justin _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

...from include/linux/preempt.h:9, from include/linux/spinlock.h:50, from include/linux/vmalloc.h:4, from fs/far/far-mem.h:23, from fs/far/far-attr.c:21: include/uapi/linux/byteorder/big_endian.h:16:0: warning: "__constant_htons" redefined [enabled by default] In file included from include/linux/byteorder/little_endian.h:4:0, from fs/far/far-attr.h:30, from fs/far/far-attr.c:19: include/uapi/linux/byteorder/little_endian.h:16:0: note: this is the location of the previous definition In...

Looks like the GSO is involved? I got this while running Dom0 only (no guests), with a BOINC/Rosetta@home application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1133! invalid opcode: 0000 [#1] SMP CPU: 0 EIP: 0061:[<c04dceb0>] Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen

...essing netmask %u.%u.%u.%u\n", NIPQUAD(ic_netmask)); - } - - return 0; -} - -/* - * RARP support. - */ - -#ifdef IPCONFIG_RARP - -static int ic_rarp_recv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt); - -static struct packet_type rarp_packet_type __initdata = { - .type = __constant_htons(ETH_P_RARP), - .func = ic_rarp_recv, -}; - -static inline void ic_rarp_init(void) -{ - dev_add_pack(&rarp_packet_type); -} - -static inline void ic_rarp_cleanup(void) -{ - dev_remove_pack(&rarp_packet_type); -} - -/* - * Process received RARP packet. - */ -static int __init -ic_rarp_recv(s...