41–50 of 52 posts
The hardware compatibility list is pretty slim at the moment: http://www.openswitch.net/documents/user/hardware-compatibil...
I couldn't even find any pricing details on the "HP Altoline" series.
$5,795.00
Earlier quoted context omitted.
The release today is about opening it up for the community participation. Making sure we release it early and not overbaked. So the community can shape the direction. We wanted to have one real HW platform that would be fully functional + Docker container image, which is being heavily used in the development and CIT. Other Broadcom Trident II/Tomahawk based platforms would be quite easy to support. For other ASICs, w…
That seems like a solid strategy. I look forward to the Tomahawk chip, but also support for Trident+ would be great, as there's a large installed base of those. And I'm sure you're already planning supporting a 32x 40Gb Trident II switch, as those are common spine switches. I could see us switching from Cumulus Linux to Open Switch, with that hardware support, and if Open Switch stays open source. We'd likely even pa…
I co-founded Cumulus Networks.
Earlier quoted context omitted.
The release today is about opening it up for the community participation. Making sure we release it early and not overbaked. So the community can shape the direction. We wanted to have one real HW platform that would be fully functional + Docker container image, which is being heavily used in the development and CIT. Other Broadcom Trident II/Tomahawk based platforms would be quite easy to support. For other ASICs, w…
So I'm guessing this gear is well out of the range of the hobbyist hacker? Is there a virtualized one I can play with instead?
This is just a land grab by HP.
Earlier quoted context omitted.
The release today is about opening it up for the community participation. Making sure we release it early and not overbaked. So the community can shape the direction. We wanted to have one real HW platform that would be fully functional + Docker container image, which is being heavily used in the development and CIT. Other Broadcom Trident II/Tomahawk based platforms would be quite easy to support. For other ASICs, w…
So I'm guessing this gear is well out of the range of the hobbyist hacker? Is there a virtualized one I can play with instead?
https://git.openswitch.net/cgit/openswitch/ops-arpmgrd/tree/...
/* Build hash key for a given vrf name and ip address */
static int
get_hash_key(char* vrf_name, char *ip, char *key)
{
sprintf(key, "%s-%s", vrf_name, ip);
return strlen(key);
} /* get_hash_key */
Definitely not thinking hard about security over there.
So I look at a random source file, and find: https://git.openswitch.net/cgit/openswitch/ops-arpmgrd/tree/... /* Build hash key for a given vrf name and ip address */ static int get_hash_key(char* vrf_name, char *ip, char *key) { sprintf(key, "%s-%s", vrf_name, ip); return strlen(key); } /* get_hash_key */ What could possibly go wrong? Definitely not thinking hard about security over there.
But, what contexts is this function used in? Is it supposed to be one-way at all? If not, then this is just a simple way of distributing vrf/ip pairs into buckets. Still smells funny, though.
EDIT: This comment looks like I'm defending the implementation here. I'm not. Seems like it'd me more uniform to just add the bytes in the vrf/IP pair and mod them with something. Seeing a hyphen in the format string of sprintf() is really weird, considering that just he string's length is being used.
Again, assuming this is in no way security-related, then this is just a general, run-of-the-mill WTF.
So I look at a random source file, and find: https://git.openswitch.net/cgit/openswitch/ops-arpmgrd/tree/... /* Build hash key for a given vrf name and ip address */ static int get_hash_key(char* vrf_name, char *ip, char *key) { sprintf(key, "%s-%s", vrf_name, ip); return strlen(key); } /* get_hash_key */ What could possibly go wrong? Definitely not thinking hard about security over there.
Ha. Kind of like PHP's function name lengths being used as a "hash" back in the day. But, what contexts is this function used in? Is it supposed to be one-way at all? If not, then this is just a simple way of distributing vrf/ip pairs into buckets. Still smells funny, though. EDIT: This comment looks like I'm defending the implementation here. I'm not. Seems like it'd me more uniform to just add the bytes in the vrf/…
I didn't even go looking for bad code. I was just curious to see what language they were using. This was near the top of the first file I looked at.
The code looks like C code circa 1990. If a first glance turned up this, what else bad is in there?
So I look at a random source file, and find: https://git.openswitch.net/cgit/openswitch/ops-arpmgrd/tree/... /* Build hash key for a given vrf name and ip address */ static int get_hash_key(char* vrf_name, char *ip, char *key) { sprintf(key, "%s-%s", vrf_name, ip); return strlen(key); } /* get_hash_key */ What could possibly go wrong? Definitely not thinking hard about security over there.
Just check Herb Sutter's talk at CppCon 2015, to the question who uses static analyzers, about 1% of the audience said yes.
Earlier quoted context omitted.
Ha. Kind of like PHP's function name lengths being used as a "hash" back in the day. But, what contexts is this function used in? Is it supposed to be one-way at all? If not, then this is just a simple way of distributing vrf/ip pairs into buckets. Still smells funny, though. EDIT: This comment looks like I'm defending the implementation here. I'm not. Seems like it'd me more uniform to just add the bytes in the vrf/…
An unchecked "sprintf" is a potential buffer overflow, especially in something like this where the input and output string buffers are parameters to the function. I didn't even go looking for bad code. I was just curious to see what language they were using. This was near the top of the first file I looked at. The code looks like C code circa 1990. If a first glance turned up this, what else bad is in there?
In a review, I'd call out requirements for buffer overflow detection outside this function.