[SCTP] last_sequence_delivered in sctp_process_a_data_chunk question
Hi, all experts: I find a suspect point in function of sctp_process_a_data_chunk in all FreeBSD branches.for example:Line 1900 of sctp_indata: (asoc->strmin[strmno].last_sequence_delivered + 1) == strmseqThis is a logical judgement sentence.last_sequence_delivered is unsigned short type, strmseq is also.there is a problem: if last_sequence_delivered equal 0x, and the result of last_sequence_delivered + 1 must be 0x1, rather than 0x, and if strmseq is also be 0x0, then this judgement will give you wrong value. so i think put a (uint16_t) before this sentence will be more secure. so how do you think?like this: (uint16_t)(asoc->strmin[strmno].last_sequence_delivered + 1) == strmseqThanks and i hope your response. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [SCTP] last_sequence_delivered in sctp_process_a_data_chunk question
On Dec 15, 2010, at 8:46 AM, 罗钰 wrote:
> Hi, all experts:I find a suspect point in function of
> sctp_process_a_data_chunk in all FreeBSD branches.for example:Line 1900 of
> sctp_indata: (asoc->strmin[strmno].last_sequence_delivered + 1) ==
> strmseqThis is a logical judgement sentence.last_sequence_delivered is
> unsigned short type, strmseq is also.there is a problem: if
> last_sequence_delivered equal 0x, and the result of
> last_sequence_delivered + 1 must be 0x1, rather than 0x, and if
> strmseq is also be 0x0, then this judgement will give you wrong value.
> so i think put a (uint16_t) before this sentence will be more secure. so how
> do you think?like this:
> (uint16_t)(asoc->strmin[strmno].last_sequence_delivered + 1) == strmseqThanks
> and i hope your response.
In head and FreeBSD 8.0 and 8.1 sctp_structs.h contains:
struct sctp_stream_in {
struct sctp_readhead inqueue;
uint16_t stream_no;
uint16_t last_sequence_delivered; /* used for re-order */
uint8_t delivery_started;
};
Furthermore sctp_process_a_data_chunk() contains:
uint16_t strmno, strmseq;
So I do not think the problem "is in all branches". Can you be more specific,
which version your are talking about?
Best regards
Michael
>
>
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy
Hi! Yes, I have PF enabled with some NAT rules present in the rule set. However disabling PF (even by commenting out 'pf_enable' in the /etc/rc.conf and rebooting the machine) does not make any difference. The problem persist regardless of whether NAT is enabled or not (or even whether pf.ko is loaded or not). Best regards, Andriy. 2010/12/15 serg vasilyev > 2009/12/9, Andriy Syrovenko : > > Hi, > > > > Well, turning off the transmit checksum offloading on the upstream > > interface solves the problem with IP checksums of IGMP report and > > leave messages always being 0. So after issuing the > > > > ifconfig re1 -txcsum > > > > command, the proxy successfully subscribes to receiving multicast > > streams, and I can see multicast UDP traffic coming in on the upstream > > interface. However there is another serious problem. Shortly alfter my > > router starts forwarding multicast traffic kernel crashes. The crash > > may happen either immediately when I press the play button in my IPTV > > player, or just after several channel switches. You can find crash > > reports in the attached files. They are almost identical, differing > > only in whether the pf module is loaded. > > > > > > The interesting part of the story is if I block incoming UDP multicast > > traffic using something like > > > > block in quick inet proto udp from any to 224.0.0.0/4 > > > > in my pf.conf, system remains stable. But as soon as I comment the > > rule and reload pf, kernel crashes. I suspect the problem is not > > strictly related to the igmp processing, but to the multicast routing > > in general. Probably something wrong with thread synchronization. My > > system is a dual-core Intel Atom. > > > > Another interesting observation is when my BSD box is disconnected > > from the upstream router, I can see only IGMPv3 messages going out the > > upstream interface, even despite the fact that igmpproxy supports > > IGMPv2 only. > > > > br, > > Andrey > > > Does your system do any nat processing ? > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Generating RTM_IFINFO messages on interface description change?
On 13 Dec, 2010, at 13:21 , Nikolay Denev wrote: > Hello, > > I'm currently trying to enable bsnmpd to export the interface > descriptions that are supported on FreeBSD 8+ as ifDescr and > while doing it I'm wondering if RTM_IFINFO msgs should be generated > on description set/change. This would greatly simplify the functionality > in bsnmpd and would prevent needless polls/ioctls. > > My opinion is that it probably is OK to generate RTM_IFINFO on this event but > are there other opinions? > > > Regards, > Nikolay Ok, This simple patch will enable the RTM_IFINFO messages when interface description is changed : --- /usr/src/sys/net.old/if.c 2010-12-15 17:32:59.0 +0100 +++ /usr/src/sys/net/if.c 2010-12-15 17:36:08.0 +0100 @@ -2176,6 +2176,7 @@ getmicrotime(&ifp->if_lastchange); free(odescrbuf, M_IFDESCR); + rt_ifmsg(ifp); break; case SIOCSIFFLAGS: With this patch the message will be generated, but without information about what changed. But I wonder if adding the description in if_data isn't too much... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Forcing Full-Duplex on Realtek card
Hello, i just discovered it seems to be impossible to force a duplex setting if the switchport is not doing autonegotiation. The server in question has a Realtek 1GBit device but the hosting company reduces the speed on their switches to 100MBit. So after booting without any options this gives me: re0: flags=8843 metric 0 mtu 1500 options=389b ether XX:XX:XX:XX:XX:XX inet 46.X.X.X netmask 0xffc0 broadcast 46.X.X.X media: Ethernet 100baseTX status: active I though this wasn't a big deal and tried to force it to full-duplex: # ifconfig re0 media 100baseTX mediaopt full-duplex but it seems the actual setting is still half-duplex: re0: flags=8843 metric 0 mtu 1500 options=389b ether XX:XX:XX:XX:XX:XX inet 46.X.X.X netmask 0xffc0 broadcast 46.X.X.X media: Ethernet 100baseTX (100baseTX ) status: active This is on a FreeBSD 8.1-RELEASE amd64 system and the hardware in questions is: r...@pci0:6:0:0:class=0x02 card=0x75221462 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet Is there anything i can do to force the full-duplex setting for good? Regards, Sascha ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Future of netnatm: looking for testers
On Wed, 28 Jul 2010, Robert Watson wrote: In reply to the original post: Dear all: When the new link layer framework was introduced in 8.0, one of our ATM stacks, netnatm, was left behind. As a result, it neither compiles nor runs in 8.x and 9.x. This e-mail serves two purposes: (1) To solicit a volunteer who can work on the netnatm stack in 9.x, with potential merge to 8.x, to get it back to functionality before 9.0 ships. This is the preferred course of action. (2) To serve as notice that if we can't find a volunteer to do this, we will remove netnatm and associated parts from the tree in 9.0 since they'll have gone one major version neither compiling nor running. This is the fallback plan. I'm in no great rush to remove netnatm, having spent quite a bit of time making it work in our MPSAFE world order a couple of years ago. However, the code is bitrotting and requires urgent attention if it's going to work again easily (the stack is changing around it, and because netnatm doesn't build, it will get only cursory and likely incorrect updates). I'm happy to help funnel changes into the tree from non-committers, as well as answer questions about the network stack, but I have no hardware facilities for debugging or testing netnatm changes myself, nor, unfortunately, the time to work on the code. In order to provide further motivation for potentially interested parties, here's the proposed six-month removal schedule: 28 July 2010- Notice of proposed removal 28 October 2010 - Transmit of notice of proposed removal 28 January 2011 - Proposed removal date This schedule may be updated as the 9.0 release schedule becomes more clear, or if there are obvious signs of improvement and just a couple more months would get it fixed :-). And, if worst comes to worst and we can't find a volunteer, the code will live on in the source repository history if there's a desire to rejuvenate it in the future. I would request two things: 1) the extra couple of months; this will not prevent the evitable removal yet only defer it. 2) If anyone of you is using (or want to be able to (continue to) use) NATM or can test things, I re-enabled it with most of the code in HEAD and the patch is available for 8,x as well but need to work with somoene to make sure it'll really work. I am willing to spend more time on it if you send me an email. Best Regards, Bjoern Author: bz Date: Wed Dec 15 22:58:45 2010 New Revision: 216466 URL: http://svn.freebsd.org/changeset/base/216466 Log: Bring back (most of) NATM to avoid further bitrot after r186119. Keep three lines disabled which I am unsure if they had been used at all. This will allow us to seek testers and possibly bring it all back. If you have the ability to test (on 8.x or HEAD) or are using NATM, please get in contact with me. Discussed with: rwatson MFC after: 7 weeks Modified: head/sys/conf/NOTES head/sys/netinet/if_atm.c -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
